Les skills OpenClaw sont des fichiers Markdown qui donnent à l’agent des instructions persistantes pour une tâche spécifique. Là où un message cron (--message "...") fournit à l’agent une invite en une ligne, un fichier de skill lui donne un manuel d’exploitation complet : quoi vérifier, comment catégoriser ce qu’il trouve, comment formater la sortie, et quel contexte propre au projet il lui faut pour accomplir correctement son travail.
Pour les tâches de monitoring, les skills déterminent si l’agent exécute dbt test et rapporte « certains tests ont échoué », ou s’il rapporte quels modèles sont affectés, le type d’échec et une action suggérée.
Anatomie d’un skill de monitoring
Les skills se trouvent dans ~/.openclaw/skills/[nom-du-skill]/SKILL.md. Il suffit de créer la structure de répertoire, d’écrire le fichier Markdown, puis de l’installer :
mkdir -p ~/.openclaw/skills/dbt-monitor# écrire SKILL.md (voir ci-dessous)openclaw skill install ~/.openclaw/skills/dbt-monitorLe fichier SKILL.md est un document Markdown ordinaire. L’agent le lit comme contexte avant d’agir sur toute requête invoquant ce skill. Il s’agit d’un document de cadrage : voici ce que vous êtes, voici ce que vous cherchez, voici comment vous devez le rapporter.
Un skill de monitoring dbt complet
# dbt test monitor
You are a dbt test monitoring assistant. When asked to check dbt tests:
1. Navigate to the dbt project directory2. Run `dbt test --target prod` and capture the output3. Parse the results into three categories: - FAIL: tests that returned failures - ERROR: tests that couldn't execute (compilation errors, connection issues) - WARN: tests configured with warning severity4. For each failure, identify: - The test name and type (unique, not_null, accepted_values, relationships, custom) - The model being tested - The number of failing rows - A suggested action based on the failure type5. Format the output as a clear summary with failures first, errors second, warnings last6. If all tests pass, say so briefly
Project directory: /path/to/your/dbt/projectLa structure en liste numérotée fonctionne bien parce qu’elle donne à l’agent une séquence explicite à suivre. L’agent ne se demande plus ce que « vérifier les tests dbt » veut dire — il dispose d’un protocole.
Distinguer les catégories d’échecs
La chose la plus importante qu’un skill de monitoring enseigne à l’agent est la différence entre les types d’échecs. La sortie de dbt test regroupe des problèmes distincts sous des messages d’apparence similaire. Votre skill doit apprendre à l’agent à les séparer.
FAIL — les données ont un problème. Un test s’est exécuté et a trouvé des lignes violant la condition du test. not_null_mrt__sales__orders_order__customer_id | FAIL 47 signifie que 47 lignes de votre mart des commandes ont un customer_id null. Le pipeline s’est exécuté avec succès ; les données sont erronées.
ERROR — le pipeline a un problème. Le test n’a pas pu s’exécuter. Les erreurs de compilation, les modèles manquants, les échecs de connexion ou les sources indéfinies produisent tous des ERRORs. Les données peuvent être correctes ; quelque chose dans l’infrastructure ou la définition du modèle a cassé.
WARN — à surveiller, sans caractère bloquant. Les tests configurés avec severity: warn signalent des problèmes sans interrompre l’exécution. Ce sont des conditions que vous avez jugées tolérables en production mais utiles à connaître.
Sans cette distinction, chaque alerte semble aussi urgente. Avec elle, vous triez immédiatement : les ERRORs signifient que quelque chose est cassé dans le pipeline lui-même et nécessite une investigation immédiate ; les FAILs peuvent signifier que les données source sont arrivées en retard ; les WARNs peuvent attendre le matin.
Ajoutez ceci explicitement à votre skill :
## Failure Type Interpretation
When you see a FAIL:- This means the data violated the test condition- Report: test name, model, failing row count- Suggested action: "Check upstream source freshness" for not_null on mart tables; "Review deduplication logic" for unique test failures
When you see an ERROR:- This means the test couldn't execute- Report: error message verbatim, model that couldn't compile- Suggested action: "Model may not exist or has a compilation error — check the dbt project"
When you see a WARN:- This means a soft threshold was exceeded- Report: which test, which model, the count- Suggested action: "Worth investigating but not blocking"Formatage Slack
L’agent envoie sa sortie sous forme de texte. Slack supporte un sous-ensemble de Markdown, vous pouvez donc guider l’agent pour produire des résumés lisibles. Point crucial : si vous ne spécifiez pas de format, l’agent en inventera un — et il sera différent à chaque fois, selon l’aspect qu’avait la sortie ce jour-là.
Ajoutez une section de formatage à votre skill :
## Formatting
Format the summary for Slack using this structure:
**dbt test results - [date]**
🔴 *X failures* | 🟡 *Y warnings* | 🟢 *Z passed*
**Failures:**- `not_null_mrt__sales__orders_order__customer_id` on `mrt__sales__orders` (47 rows) → Likely cause: upstream source load incomplete. Check source freshness.- `unique_mrt__sales__customers_customer__id` on `mrt__sales__customers` (3 rows) → Likely cause: duplicate records in source. Review deduplication logic.
**Warnings:**- `accepted_values_int__orders_enriched_order__status` on `int__orders_enriched` (2 rows outside expected values)
All other tests passed (142/147).Les backticks autour des noms de modèles et de tests créent un formatage monospace dans Slack, les rendant visuellement distincts du texte courant. La flèche → pour les actions suggérées crée un pattern visuel cohérent facile à parcourir. Le nombre total de tests passés à la fin donne le contexte du nombre de tests verts.
Le format de template est intentionnel : vous donnez à l’agent un exemple sur lequel s’appuyer, pas une description de règles à suivre. Lui montrer un exemple de sortie est plus fiable que de décrire la sortie en termes abstraits.
Ajouter le contexte d’impact en aval
Un message d’échec brut crée de l’anxiété. Un message qui inclut l’impact en aval vous permet de trier depuis votre téléphone sans ouvrir un ordinateur portable.
Ajoutez à votre skill :
## Downstream Impact
For each failed model, also run:`dbt ls --select +[model_name]`
This lists downstream models that depend on the failing model. Include this in the report:- If 0 downstream models: "No downstream impact"- If 1-3 downstream models: list them- If 4+ downstream models: "Affects [count] downstream models including [most important one]"Cela vous indique si un échec dans un modèle de base signifie que cinq dashboards affichent des données périmées ou qu’un seul modèle intermédiaire inutilisé est cassé. La différence détermine l’urgence de votre réponse.
Le sélecteur + dans dbt ls signifie « tout ce qui est en aval de ce modèle ». L’exécuter par modèle en échec ajoute du temps au job de monitoring, utilisez donc votre jugement : vous pouvez ne vouloir l’impact en aval que pour les échecs de la couche mart, pas pour chaque avertissement de modèle intermédiaire.
La fraîcheur des sources comme vérification préalable aux tests
Certains échecs de tests ne sont pas des problèmes de qualité de données — ce sont des problèmes de timing. Un échec not_null sur un modèle mart à 7h du matin peut signifier que le chargement source nocturne n’était pas terminé quand dbt s’est exécuté. Ajouter une vérification de la fraîcheur des sources avant l’exécution des tests donne à l’agent le contexte pour interpréter ce qu’il trouve.
## Pre-Test Freshness Check
Before running `dbt test`, run `dbt source freshness` and capture the output.
If any sources are stale (beyond their configured warn or error thresholds), include this at the top of the report:"⚠️ Source freshness warning: [source_name] last loaded [time_ago]. Test failures may be caused by incomplete source data."
This helps distinguish "data is wrong" from "data hasn't arrived yet."C’est particulièrement précieux pour les jobs de monitoring matinaux. Si votre sync Fivetran tourne à 5h et prend parfois jusqu’à 7h pour les gros syncs, la sortie de vérification de fraîcheur de l’agent explique un pattern qui ressemblerait sinon à des échecs récurrents de qualité de données.
Calibrer le skill au fil du temps
La première version d’un skill de monitoring sera imparfaite. Les catégorisations de l’agent seront parfois incorrectes. Le format ne correspondra pas tout à fait à ce que vous vouliez. Certaines actions suggérées seront trop génériques.
Traitez le fichier de skill comme un document vivant. Quand l’agent mal-interprète quelque chose, ajoutez une clarification. Quand le format de sortie n’est pas utile, mettez à jour le template. Quand un nouveau type d’échec commence à apparaître que le skill ne gère pas bien, ajoutez-y une section.
C’est la même boucle d’itération que vous appliqueriez à n’importe quel prompt. La différence est que les fichiers de skills sont persistants — vous les éditez une fois et chaque exécution future bénéficie de l’amélioration. Un message de prompt cron est statique ; un fichier de skill évolue avec votre connaissance opérationnelle.
Le flux de travail pratique : quand une alerte de monitoring se déclenche et que vous la triez, notez si la description de l’agent était précise et si l’action suggérée était juste. Si l’un ou l’autre était erroné, mettez à jour le skill immédiatement pendant que le contexte est frais. Sur un mois d’échecs hebdomadaires, le skill accumule de véritables connaissances opérationnelles sur les modes d’échec spécifiques de votre pipeline.
Skills de monitoring BigQuery et Snowflake
Le même pattern de skill s’applique aux tâches de monitoring d’entrepôt. Pour le monitoring des échecs de jobs BigQuery, le skill instruit l’agent à exécuter une requête SQL spécifique contre INFORMATION_SCHEMA.JOBS et à interpréter les résultats — voir Monitoring des échecs de jobs BigQuery pour les requêtes.
Pour le monitoring des coûts Snowflake, le skill enseigne à l’agent la conversion crédit-en-dollars et comment formuler les résultats pour les parties prenantes non techniques — voir Monitoring des coûts Snowflake avec l’historique des warehouses pour les patterns spécifiques à Snowflake.
La structure de base est la même quel que soit le système cible : définir quoi vérifier, comment catégoriser ce que l’on trouve, et comment formater la sortie. Les spécificités changent selon ce que retourne le système sous-jacent.