Vous avez configuré un skill pour les conventions de votre projet dbt. Vous vous attendez à ce que Claude l’utilise automatiquement quand vous lui demandez de créer un modèle de base. Il ne le fait pas. Vous finissez par taper « et utilise le skill » à la fin de chaque prompt. Après quelques jours, vous vous demandez : à quoi bon ?

Cette confusion est courante, et elle vient de l’écart entre le marketing des skills et leur comportement réel.

Ce sont tous deux des fichiers markdown, mais ils fonctionnent dans des directions opposées

Les commandes sont simples. Vous tapez /audit-model, Claude l’exécute. Vous contrôlez quand ça se passe.

Les skills fonctionnent différemment. Claude lit la description de chaque skill au démarrage et est censé décider quand les appliquer en fonction de votre requête. L’idée est que vous décrivez vos conventions dbt une fois, et Claude les suit automatiquement quand c’est pertinent. Élégant en théorie.

En pratique, les tests de la communauté montrent que les skills ne s’activent automatiquement qu’environ 20% du temps. On lit souvent : « Je dois toujours dire ‘mets à jour les notes de processus et utilise ton skill.’ C’est trop verbeux pour moi. Alors j’ai simplement créé une slash command. » C’est aussi mon expérience. Vous configurez un skill en attendant de la magie, puis vous finissez par le déclencher explicitement de toute façon, ce qui en annule l’intérêt.

Le problème est la correspondance de mots-clés. Claude charge le name et la description de chaque skill depuis le frontmatter YAML et vérifie les correspondances quand vous faites une requête. Si votre description n’inclut pas les bons mots déclencheurs, ou si vous formulez les choses différemment de ce qui est attendu, le skill reste inutilisé.

Pour le travail data, ça compte plus qu’il n’y paraît

Quand je lance un audit dbt ou que je génère de la documentation de lineage, je veux les mêmes vérifications à chaque fois. La cohérence n’est pas optionnelle — c’est tout l’enjeu. Un workflow qui fonctionne 20% du temps n’est pas un workflow, c’est un pari.

C’est pourquoi je me suis tourné vers les commandes pour tout ce que je fais de façon répétée. Une commande /audit-model qui vérifie la couverture de documentation, la présence de tests et la conformité des noms. Une commande /document-lineage qui génère des diagrammes Mermaid. Une commande /pre-commit pour la séquence de validation standard avant de pousser mes modifications.

Celles-ci s’exécutent de la même façon à chaque fois parce que je les déclenche explicitement. Pas besoin d’espérer que Claude décide d’appliquer le bon contexte.

Les skills ont toujours leur place, mais elle est assez restreinte. Ils fonctionnent mieux pour les connaissances de domaine qui doivent informer le travail de Claude à travers différentes tâches : les particularités spécifiques à votre entrepôt de données, les conventions d’équipe, la documentation de référence que vous voulez disponible mais pas nécessairement invoquée explicitement. Le genre de contexte d’arrière-plan qui façonne l’approche de Claude face aux problèmes plutôt que des workflows spécifiques que vous voulez déclencher.

À quoi ça ressemble en pratique

Voici un example de commande pour les audits de modèles. Elle se trouve dans .claude/commands/audit-model.md :

---
allowed-tools: Bash(dbt:*), Bash(cat:*), Bash(grep:*)
description: Audit a dbt model for documentation and test coverage
---

Audit the model at $ARGUMENTS:

1. Check schema.yml exists and has descriptions for model and columns
2. Verify unique + not_null tests on primary key
3. Check naming follows our convention (base__, int__, mrt__)
4. List any undocumented columns
5. Show the model's direct upstream dependencies

Output a summary with pass/fail for each check.

On l’exécute avec /audit-model models/marts/mrt__daily_revenue.sql et on obtient des résultats cohérents à chaque fois.

Comparez ça à une approche par skill. Vous pourriez créer un skill avec tous vos critères d’audit, en espérant que Claude l’applique quand vous dites « vérifie ce modèle ». Parfois il le fera. Souvent non. Et quand il ne le fait pas, vous revenez à taper ce que vous vouliez de toute façon.

Pour quelque chose comme la documentation de lineage, on peut utiliser les deux. Le skill regroupe les templates Mermaid et les conventions pour générer des diagrammes. La commande donne un déclencheur fiable quand on veut spécifiquement de la documentation de lineage. La présence du skill signifie que Claude pourrait le reprendre automatiquement dans d’autres contextes ; la commande garantit qu’on peut le forcer quand ça échoue.

Si vous comptez sur les skills, la rédaction de la description aide. Le pattern qui fonctionne le mieux inclut des mots déclencheurs explicites et des exclusions :

description: Generate data lineage documentation and Mermaid diagrams.
  Use when user asks about lineage, dependencies, upstream models,
  or documentation for model relationships. Do NOT use for general
  dbt questions unrelated to lineage.

Le spécifique bat le générique. « Lineage » et « dependencies » fonctionnent mieux que « documentation utilities ».

Où j’en suis arrivée

Ma configuration maintenant est assez simple. Les commandes gèrent tout workflow que j’exécute plus de quelques fois. Les skills contiennent les connaissances de référence qui informent plusieurs commandes. Et CLAUDE.md capture le contexte à l’échelle du projet qui s’applique à tout : conventions de nommage, style SQL, patterns spécifiques à l’entrepôt de données.

La fonctionnalité la plus sophistiquée n’est pas toujours la meilleure. Pour le travail data, je préfère le prévisible à l’automatique.

Cet article fait partie de ma série sur Claude Code pour l’analytics engineering. Si vous débutez, Claude Code pour les gens de la data explique ce que c’est vraiment, et Comment j’utilise Claude Code pour le développement dbt détaille les workflows qui ont perduré.