Générateur de Diagramme de Base de Données EF Core D2

Quand l'utiliser

Utilisez cette skill quand l'utilisateur souhaite générer un diagramme de base de données / ERD à partir d'une base de code Entity Framework Core.

Demandes typiques :

Générer un diagramme de base de données D2 à partir d'entités EF Core.
Visualiser les tables, colonnes, clés primaires, clés étrangères et relations.
Analyser DbContext, DbSet<T>, IEntityTypeConfiguration<T>, Fluent API et migrations.
Produire un fichier .d2 rendable en SVG/PNG avec la CLI d2.
Documenter le modèle de base de données d'un projet ASP.NET Core / .NET.

Objectif

Créer un diagramme entité-relation D2 lisible qui reflète le modèle de persistance EF Core réel, pas uniquement la forme brute de la classe C#.

Le diagramme doit privilégier :

Les tables de base de données et les relations.
Les clés primaires, clés étrangères, colonnes requises/optionnelles.
Les types possédés et objets de valeur.
Les relations plusieurs-à-plusieurs et tables de jointure.
Les index, contraintes uniques et noms de table.
Les conventions EF Core uniquement quand le mappage explicite est absent.

La sortie est du code source .d2. Il peut être rendu en SVG ou PNG via la CLI d2.

Outils

d2 CLI : rendre les fichiers .d2 en SVG/PNG.
- d2 input.d2 output.svg
- d2 --layout=elk input.d2 output.svg
d2 fmt : formater les fichiers D2.
- d2 fmt input.d2
Aucun serveur MCP n'est requis. La skill génère le code source D2 sous forme de texte.

Flux de Travail Recommandé

Lire la structure du projet EF Core.
Localiser toutes les classes DbContext.
Localiser toutes les déclarations DbSet<T>.
Localiser les classes d'entité, types possédés, types enum et objets de valeur.
Lire OnModelCreating et toutes les classes IEntityTypeConfiguration<T>.
Lire les migrations quand disponibles pour confirmer les noms de table, tables de jointure, index et comportements de suppression.
Construire un modèle de base de données normalisé avant d'écrire D2.
Poser le questionnaire obligatoire du diagramme avant la génération.
Générer le fichier .d2 en utilisant le modèle de base de données, pas l'imbrication brute des classes.
Valider la syntaxe D2 avec d2 fmt avant livraison.
Rendre avec d2 --layout=elk schema.d2 schema.svg si possible.
En cas de régénération, relire d'abord les mappages EF Core et les migrations.

Questions Obligatoires Avant la Génération du Diagramme

Posez ces questions pour chaque nouveau diagramme et chaque régénération, sauf si l'utilisateur y a déjà répondu dans la même demande.

Quel DbContext doit être diagrammé ? (auto-detect/all/specific name)
Afficher les colonnes ? (all/key-only/none)
Afficher les types de colonne ? (Yes/No)
Afficher les marqueurs nullable/required ? (Yes/No)
Afficher les index et contraintes uniques ? (Yes/No)
Afficher les valeurs d'énumération ? (Yes/No)
Afficher les types possédés ? (inline/separate/hide)
Afficher les tables de jointure plusieurs-à-plusieurs ? (explicit/compact/hide)
Afficher les tables techniques/d'audit ? (Yes/No)
Afficher les tables de migration-only absentes en tant qu'entités ? (Yes/No)
Quel mode de groupement ? (bounded-context/schema/namespace/flat)
Quel moteur de layout ? (elk/dagre/tala)
Quel format de sortie ? (d2/svg/png)

Valeurs par défaut, quand l'utilisateur demande une génération rapide :

DbContext : auto-detect
Colonnes : key-only
Types de colonne : Yes
Marqueurs nullable : Yes
Index : Yes
Énumérations : No
Types possédés : inline
Tables de jointure : explicit
Tables techniques/d'audit : No
Tables migration-only : Yes
Groupement : bounded-context
Layout : elk
Sortie : d2

Documents de Référence

Charger à la demande quand nécessaire :

Référence	Quand charger
`references/efcore-model-extraction.md`	Règles pour lire DbContext, DbSet, Fluent API, configurations et migrations
`references/d2-erd-style.md`	Syntaxe D2 et conventions visuelles pour les diagrammes ERD
`references/relationship-rules.md`	Comment déduire les relations un-à-un, un-à-plusieurs, plusieurs-à-plusieurs et possédées
`references/grouping-modes.md`	Règles pour les groupements bounded-context, schema, namespace et flat
`references/quality-gate.md`	Liste de vérification finale avant livraison du diagramme généré

Règles d'Extraction EF Core

Priorité des Sources

Utilisez cet ordre de priorité quand les sources divergent :

Dernière migration appliquée / snapshot de migration.
Configuration Fluent API dans OnModelCreating ou IEntityTypeConfiguration<T>.
Annotations de données.
Conventions EF Core.
Forme brute de la classe C#.

Concepts EF Core Requis à Détecter

Détecter et représenter :

DbContext et DbSet<T>.
Noms de classe d'entité et noms de table réels depuis ToTable.
Noms de schéma depuis ToTable("Table", "schema").
Clés primaires depuis HasKey, [Key], conventions et migrations.
Clés composites.
Clés étrangères depuis HasForeignKey, propriétés de navigation et opérations de migration.
Comportement de suppression quand explicite : Cascade, Restrict, NoAction, SetNull, ClientSetNull.
Marqueurs de relation requis/optionnels.
Types possédés depuis OwnsOne, OwnsMany et [Owned].
Relations plusieurs-à-plusieurs depuis UsingEntity et tables de jointure EF Core implicites.
Index depuis HasIndex, IsUnique et migrations.
Clés alternatives depuis HasAlternateKey.
Propriétés shadow configurées en Fluent API.
Conversions de valeur quand elles affectent le type persisté ou la lisibilité.
Propriétés d'énumération.
Propriétés et entités ignorées.

Règles de Rendu du Diagramme

Tables

Représenter chaque table persistée en tant que nœud D2 avec shape: sql_table si possible.

Utiliser cette convention de contenu :

Clients: {
  shape: sql_table
  constraint: primary_key
  Id: uuid {constraint: primary_key}
  Name: text
  Status: enum
}

Si sql_table n'est pas disponible ou cause des problèmes de validation, basculer vers un rectangle avec du texte structuré.

Relations

Utiliser des arêtes directionnelles de la table dépendante vers la table principale.

Les étiquettes doivent inclure la cardinalité de relation et le nom de la FK quand connu :

Offers.ClientId -> Clients.Id: "N:1 FK_Offers_Clients_ClientId"

Utiliser ces étiquettes de cardinalité :

1:1
1:N
N:1
N:N
owned

Types Possédés

Les types possédés par défaut sont rendus en ligne.

Exemple en ligne :

Clients: {
  shape: sql_table
  Id: uuid {constraint: primary_key}
  Address.Street: text
  Address.ZipCode: text
  Address.City: text
}

Si l'utilisateur choisit separate, représenter les types possédés en tant que tables visuellement subordonnées et utiliser une relation owned.

Plusieurs-à-Plusieurs

Par défaut, utiliser des tables de jointure explicites car EF Core crée des tables réelles.

Pour les relations plusieurs-à-plusieurs implicites, créer un nœud de table de jointure généré et le marquer comme implicit join.

Tables Techniques

Masquer les tables techniques par défaut, sauf si demandé.

Exemples :

__EFMigrationsHistory
Tables Hangfire
Tables ASP.NET Identity
Journaux d'audit
Tables Outbox

Si les tables techniques sont masquées, les mentionner dans le résumé après le diagramme.

Modes de Groupement

bounded-context : grouper par domaine détecté ou dossier/module.
schema : grouper par schéma de base de données, par exemple public, auth, billing.
namespace : grouper par namespace C#.
flat : aucun conteneur, toutes les tables au même niveau.

Règles de Style

Utiliser des styles cohérents :

Tables d'entité principale : bordure unie.
Tables de jointure : bordure en pointillés.
Types possédés : trait plus léger ou champs imbriqués en ligne.
Tables techniques : style atténué.
Tables externes ou migration-only : bordure pointillée.
Relations requises : ligne unie.
Relations optionnelles : ligne en pointillés.
Suppression en cascade : suffixe d'étiquette cascade.

Porte de Qualité Avant Livraison

Avant de livrer le diagramme, vérifier :

[ ] Le DbContext sélectionné est clair.
[ ] Toutes les entités DbSet<T> sont considérées.
[ ] Les configurations Fluent API sont lues.
[ ] Les migrations sont vérifiées quand présentes.
[ ] Les noms de table et les noms de schéma correspondent au mappage EF Core.
[ ] Les clés primaires sont présentes.
[ ] Les clés étrangères et cardinalités sont représentées.
[ ] Les types possédés sont gérés selon le choix de l'utilisateur.
[ ] Les tables de jointure plusieurs-à-plusieurs sont explicites, sauf si l'utilisateur demanda autrement.
[ ] Les tables techniques masquées sont listées dans le résumé final.
[ ] La syntaxe D2 est valide avec d2 fmt.
[ ] Les extrémités d'arêtes utilisent la notation complète en point-séparé quand à l'intérieur de conteneurs.
[ ] Le diagramme reste lisible et évite les layouts chargés de croisements.

Format de Sortie

Quand l'utilisateur demande une installation de skill, fournir cette structure de dossier :

.github/
  skills/
    efcore-d2-db-diagram/
      SKILL.md
      references/
        efcore-model-extraction.md
        d2-erd-style.md
        relationship-rules.md
        grouping-modes.md
        quality-gate.md

Quand l'utilisateur demande de générer un diagramme, fournir :

Le contenu du fichier source .d2.
La commande de rendu utilisant le moteur de layout sélectionné.
Un résumé concis des hypothèses et tables masquées.