4 skills pretes a adapter pour la data#

.claude/skills/audit-qualite-dataset/
├── SKILL.md
├── scripts/profil_dataset.py
└── reference/seuils-qualite.md

---
name: audit-qualite-dataset
description: Audite la qualite d'un jeu de donnees (valeurs manquantes, doublons, types,
  cardinalite, valeurs aberrantes) et rend un rapport structure avec un verdict
  exploitable ou non. A utiliser quand l'utilisateur recoit un nouveau fichier CSV ou
  Parquet, charge une table, parle de qualite de donnees, de profiling, de valeurs
  manquantes, de doublons, ou demande si un dataset est fiable.
argument-hint: [chemin-du-fichier-ou-nom-de-table]
allowed-tools: Read, Glob, Bash(python *profil_dataset.py*)
---

# Audit qualite d'un dataset

## Procedure

- [ ] Etape 1 : profiler le dataset
- [ ] Etape 2 : comparer aux seuils de l'equipe
- [ ] Etape 3 : verifier les regles metier
- [ ] Etape 4 : rendre le rapport et le verdict

### Etape 1 : profiler

Execute le script, ne regenere pas son code :
`python ${CLAUDE_SKILL_DIR}/scripts/profil_dataset.py $ARGUMENTS`

Il sort un JSON : nombre de lignes, et par colonne le type, le taux de nuls, le
nombre de valeurs distinctes, les 5 valeurs les plus frequentes, min, max, moyenne.

### Etape 2 : comparer aux seuils

Les seuils de tolerance de l'equipe sont dans
[reference/seuils-qualite.md](reference/seuils-qualite.md). Lis ce fichier avant de
juger. Ne fixe jamais de seuil de ton propre chef.

### Etape 3 : regles metier

- la cle primaire [NOM_DE_LA_CLE_PRIMAIRE] est unique et non nulle
- aucune date n'est dans le futur
- les montants sont positifs, sauf sur les lignes d'avoir
- les lignes de test sont exclues : [REGLE_D_EXCLUSION_DES_TESTS]

### Etape 4 : format du rapport

Ligne 1 : un verdict unique parmi EXPLOITABLE, EXPLOITABLE AVEC RESERVES,
NON EXPLOITABLE.
Puis un tableau : Colonne | Probleme | Gravite | Nombre de lignes | Action proposee.
Puis une section Ce qui est OK, en 3 puces maximum.

Ne propose aucune correction avant d'avoir rendu ce rapport.

.claude/skills/documenter-modele-dbt/
├── SKILL.md
└── reference/modele-schema-yml.md

---
name: documenter-modele-dbt
description: Genere ou met a jour la documentation dbt d'un modele dans schema.yml
  (description du modele, description de chaque colonne, tests unique et not_null sur
  la cle) a partir du SQL du modele. A utiliser quand l'utilisateur cree ou modifie un
  fichier dans models/, parle de dbt docs, de schema.yml, de documentation de modele,
  de description de colonnes ou de tests dbt.
argument-hint: [nom-du-modele]
paths: models/**
allowed-tools: Read, Grep, Glob
---

# Documentation d'un modele dbt

## Modeles modifies recemment

!`git diff --name-only HEAD -- models/`

## Procedure

- [ ] Etape 1 : lire le SQL du modele vise par $ARGUMENTS
- [ ] Etape 2 : lire le schema.yml existant du meme dossier
- [ ] Etape 3 : rediger les descriptions manquantes
- [ ] Etape 4 : ajouter les tests
- [ ] Etape 5 : verifier la couverture

N'ecrase jamais une description existante : complete seulement ce qui manque.

### Etape 3 : rediger les descriptions

- Une phrase par colonne, en francais, a l'indicatif present.
- Dire ce que contient la colonne, pas son type : le type est deja dans la base.
- Preciser l'unite quand il y en a une : euros, centimes, jours, UTC.
- Pour une cle etrangere, nommer la table cible.
- Interdit : repeter le nom de la colonne. `client_id` decrit par Identifiant du
  client est inutile. Ecris plutot la granularite et l'origine.

Le format exact attendu est dans
[reference/modele-schema-yml.md](reference/modele-schema-yml.md).

### Etape 4 : tests

Au minimum sur la cle primaire : `unique` et `not_null`.
`accepted_values` sur toute colonne de statut ou de type.
`relationships` sur toute colonne finissant par `_id` qui pointe vers une dimension.

### Etape 5 : verification

Compare la liste des colonnes du `select` final avec la liste des colonnes
documentees. Si une colonne manque, retourne a l'etape 3.
Annonce le taux de couverture : X colonnes documentees sur Y.

.claude/skills/generer-tests-donnees/
├── SKILL.md
└── reference/catalogue-tests.md

---
name: generer-tests-donnees
description: Propose et ecrit une batterie de tests de donnees pour une table ou un
  modele (unicite, non-nullite, valeurs acceptees, integrite referentielle, fraicheur,
  coherence metier), dans le format de test du projet. A utiliser quand l'utilisateur
  parle de tests de donnees, de data quality, de dbt test, de Great Expectations, de
  contrat de donnees, ou demande comment verifier qu'une table est correcte.
argument-hint: [nom-de-la-table]
allowed-tools: Read, Grep, Glob
---

# Generation de tests de donnees

Un bon test repond a la question : qu'est-ce qui doit etre vrai en permanence sur
cette table ? Ne propose jamais un test qui ne peut pas echouer.

## Procedure

- [ ] Etape 1 : identifier la granularite
- [ ] Etape 2 : couvrir les 5 familles de tests
- [ ] Etape 3 : ecrire les tests dans le format du projet
- [ ] Etape 4 : classer par priorite

### Etape 1 : granularite

Ecris d'abord, en une phrase : une ligne de cette table represente [QUOI].
Tout le reste en decoule. Si tu ne sais pas, demande avant de continuer.

### Etape 2 : les 5 familles

1. Unicite : la cle de grain est-elle unique ?
2. Completude : quelles colonnes ne doivent jamais etre nulles ?
3. Domaine : quelles colonnes ont un ensemble fini de valeurs possibles ?
4. Integrite : quelles cles etrangeres doivent exister dans la table cible ?
5. Coherence metier : total egal a la somme des lignes, date_fin apres date_debut,
   taux entre 0 et 1.

Le detail de chaque famille, avec la syntaxe exacte, est dans
[reference/catalogue-tests.md](reference/catalogue-tests.md).

### Etape 3 : format

Le projet utilise [FORMAT_DE_TEST : dbt tests dans schema.yml / Great Expectations /
pytest + SQL]. Ecris dans ce format uniquement, ne melange pas les formats.

### Etape 4 : priorite

- BLOQUANT : le pipeline doit s'arreter
- ALERTE : on previent, on continue
- INFO : on mesure, on ne bloque pas

Rends un tableau : Test | Famille | Priorite | Ce que ca detecte.

.claude/skills/formater-rapport-analyse/
├── SKILL.md
└── reference/plan-rapport.md

---
name: formater-rapport-analyse
description: Met en forme les resultats d'une analyse de donnees en rapport structure
  pour un lecteur non technique : message principal, chiffres cles, methode, limites et
  recommandations. A utiliser quand l'utilisateur a fini une analyse, veut restituer des
  resultats, parle de rapport, de synthese, de restitution, de note d'analyse ou de
  presentation de chiffres.
argument-hint: [sujet-de-l-analyse]
---

# Mise en forme d'un rapport d'analyse

## Regles non negociables

1. Le message principal est en premiere ligne, en une phrase, avec le chiffre.
   Jamais de suspense, jamais de deroule chronologique de la methode.
2. Tout chiffre est accompagne de sa periode et de son perimetre.
3. Toute variation est donnee en valeur ET en pourcentage.
4. Aucun jargon technique dans les deux premieres sections : pas de nom de table,
   pas de SQL, pas de nom de colonne.
5. Les limites de l'analyse sont toujours ecrites. Une analyse sans limites
   declarees n'est pas credible.

## Structure imposee

1. Le message en une phrase
2. Les 3 chiffres cles : Indicateur | Valeur | Variation | Periode
3. Ce qu'on observe : 3 a 5 puces factuelles
4. Ce qu'on en deduit : 2 a 3 puces d'interpretation, separees des faits
5. Limites et precautions de lecture
6. Recommandations : 2 a 3 actions, chacune avec son effet attendu
7. Annexe methode : sources, filtres, requetes, pour les lecteurs techniques

Le modele detaille avec un exemple rempli est dans
[reference/plan-rapport.md](reference/plan-rapport.md).

## Contexte de l'equipe

- Le lecteur type est [PROFIL_DU_LECTEUR : direction commerciale, produit, finance].
- Les indicateurs officiels et leur definition sont [OU_SONT_LES_DEFINITIONS].
- L'exercice fiscal va du [DATE_DEBUT] au [DATE_FIN].
- La monnaie est [DEVISE], les montants sont [TTC_OU_HT].

## Verification avant livraison

- [ ] La premiere phrase contient le message et un chiffre
- [ ] Chaque chiffre a sa periode et son perimetre
- [ ] Faits et interpretations sont dans des sections separees
- [ ] Les limites sont ecrites
- [ ] Aucun nom de table dans les sections 1 a 6

Si un point echoue, corrige et recommence la verification.

Voici une skill generique que je veux adapter a mon contexte :
[COLLE_LE_SKILL_MD_CI_DESSUS]

Mon contexte reel :
- entrepot / base : [BIGQUERY / SNOWFLAKE / POSTGRES / DUCKDB]
- tables concernees : [TABLE_1], [TABLE_2]
- cle primaire type : [NOM_DE_LA_CLE]
- regle d'exclusion des lignes de test : [LA_REGLE_EXACTE]
- outil de tests utilise : [DBT / GREAT_EXPECTATIONS / PYTEST]
- unite des montants : [EUROS / CENTIMES]

Remplace tous les champs entre crochets par mes valeurs.
Ne rallonge pas le SKILL.md : si tu ajoutes du detail, mets-le dans
reference/[NOM_FICHIER].md et lie-le depuis le SKILL.md.
Rends-moi les fichiers complets, prets a coller.