nedeadinside/likec4-skill

Diagrammes C4 avec LikeC4

Produisez des diagrammes C4 valides en DSL LikeC4 à partir d'une description verbale ou d'un codebase, et validez-les avec le CLI avant livraison. Les références sont réparties par préoccupation — lisez uniquement ce dont la tâche a besoin, avant d'écrire cette partie ; ne devinez pas la syntaxe.

Tout ce qui est ici est vérifié avec likec4 1.59.2 (voir references/setup-and-validation.md pour la procédure de verrouillage et de mise à niveau).

Règles strictes (seulement deux)

1. Validez avant de livrer. Exécutez likec4 validate sur le projet et ne livrez que si le code de sortie est 0. Si aucun CLI n'est disponible → effectuez l'auto-vérification documentée et divulguez-la. Procédure : references/setup-and-validation.md.
2. N'inventez jamais la syntaxe DSL. En cas de doute, ouvrez la référence appropriée ; si vous doutez encore, consultez https://likec4.dev/dsl/.

Configuration (à faire en premier, une fois par session)

LC4="npx -y [email protected]"
v="$(likec4 --version 2>/dev/null | grep -oE '^[0-9]+\.[0-9]+\.[0-9]+' | tail -1)"
[ -n "$v" ] && [ "$(printf '%s\n1.53.0\n' "$v" | sort -V | head -1)" = "1.53.0" ] && LC4=likec4

Un CLI installé n'est utilisé qu'à partir de >= 1.53.0 — les versions antérieures n'ont pas de commande format et la 1.52.0 sort avec le code 0 sur les modèles invalides, donc les deux vérifications ci-dessous passeraient silencieusement. Aucune installation globale requise — npx -y [email protected] fonctionne dans tout environnement avec Node 22+ et un accès réseau (premier téléchargement, puis mis en cache). Pour les projets que l'utilisateur conserve, recommandez npm install --save-dev [email protected]. Détails, version minimale, repli hors ligne et catalogue d'erreurs : references/setup-and-validation.md.

Tâche → quoi lire

Tâche à accomplir	Lire
Contexte système / Paysage ("qui l'utilise, à quoi il parle")	references/levels/l1-context.md
Conteneurs ("ce qui s'exécute à l'intérieur", choix techniques)	references/levels/l2-container.md
Composants (à l'intérieur d'un conteneur)	references/levels/l3-component.md
Niveau code — classes/interfaces d'un composant	references/levels/l4-code.md
Flux de données / scénario / séquence (connexion, paiement, pipeline)	references/levels/flows-dynamic.md
Infrastructure / "où cela s'exécute-t-il"	references/levels/deployment.md
Toute question DSL transversale (spec, model, FQN, extend, prédicats)	references/syntax-core.md
Couleurs, formes, icônes, légende, disposition	references/styling.md
Étant donné un dépôt / code source	references/code-to-diagram.md
Installer, valider, formater, erreurs, prévisualiser/exporter/CI	references/setup-and-validation.md

Adapter la structure à la tâche

• Demande simple (un système, aperçu rapide du contexte/conteneurs) : partez de templates/minimal/ — 3 fichiers (spec.c4, model.c4, views.c4). Ne construisez pas de projet multi-dossiers pour cela.
• Système réel (2+ niveaux, plusieurs systèmes, déploiement, flux) : utilisez la disposition templates/full/ — copiez les fichiers et renommez le contenu :

architecture/
├── spec.c4                 # le SEUL bloc de specificat ion : tous les types
├── model/
│   ├── landscape.c4        # systèmes de plus haut niveau + acteurs
│   ├── <system>.c4         # un fichier par système, via extend <system> { … }
│   └── externals.c4        # éléments externalSystem
├── deployment/prod.c4      # nœuds + instanceOf (les types restent dans spec.c4)
└── views/
    ├── context.c4          # Niveau 1 (index de vues)
    ├── <system>-views.c4   # Vues Niveau 2/3 avec exploration
    └── dynamic-flows.c4    # vues dynamiques + déploiement

Développez en ajoutant des fichiers (nouveau système → nouveau model/<s>.c4), gardez le modèle séparé des vues, et conservez la specificat ion dans un seul fichier. Tous les fichiers .c4 sous le dossier se fusionnent automatiquement en un seul modèle.

Les templates utilisent uniquement les couleurs de thème intégrées (en périmètre = primary, externe = gray via le type externalSystem, personne = indigo) — pas de couleurs personnalisées, pas de tags. Cela respecte la convention C4 et s'adapte aux thèmes clairs/sombres.

Flux de travail

1. Cadrage — identifiez le système, les acteurs, les externes ; choisissez les niveaux. Par défaut : Contexte + Conteneur ; Composant uniquement pour un conteneur non trivial ; une vue dynamique pour chaque scénario clé (recommandé) ; déploiement quand l'infrastructure compte ; Niveau 4 uniquement sur demande explicite ou justification claire (references/levels/l4-code.md — le substitut par défaut est un lien source). Entrée : dépôt → references/code-to-diagram.md. Périmètre vraiment ambigu → posez une question ; sinon, avancez et indiquez les hypothèses.
2. Configuration — copiez le template correspondant, exécutez la ligne LC4 ci-dessus.
3. Modélisez, puis vues — écrivez les fichiers de modèle, puis les vues avec exploration (view of, navigateTo), en lisant le fichier de niveau pour chaque diagramme que vous produisez.
4. Validez, puis formatez — $LC4 validate <dir> ; corrigez les erreurs Ligne N: (catalogue dans setup-and-validation.md) jusqu'à ce que le code de sortie soit 0. Ensuite `$LC4 format
5. Livrez — montrez l'arborescence des fichiers, le résultat de la validation et comment visualiser les diagrammes ($LC4 start <dir> ; options d'export/CI dans setup-and-validation.md).

Barre de qualité (vérifiez avant livraison)

• likec4 validate code de sortie 0 (ou auto-vérification divulguée), stderr propre.
• likec4 format <dir> --check code de sortie 0 — les fichiers sont en forme canonique.
• Chaque élément a une description ; chaque conteneur/composant a une technology ; chaque relation a une étiquette dirigée (quoi + comment).
• Chaque vue a un title ; ≤ ~20 éléments par vue — divisez les vues surchargées.
• Les niveaux sont connectés : Contexte → Conteneur → Composant via view of / navigateTo.