3 skills pretes a copier#

~/.claude/skills/ma-skill/
├── SKILL.md          (obligatoire)
├── reference.md      (facultatif, charge a la demande)
└── scripts/
    └── helper.py     (facultatif)

---
name: clarifier-mon-texte
description: Transforme des notes brouillonnes en texte professionnel clair en francais. A utiliser pour un mail, un ticket, un message d'equipe, un compte rendu ou une note technique.
argument-hint: [type de texte : mail | ticket | compte-rendu | note]
disable-model-invocation: true
---

# Clarifier mon texte

Type de texte demande : $ARGUMENTS

Le texte a retravailler suit ce message. Il peut etre desordonne, incomplet, avec des
phrases non terminees : c'est normal, c'est de la matiere brute.

## Ce que tu fais

1. Tu identifies l'intention : qu'est-ce que l'auteur veut obtenir du destinataire ?
2. Tu ecris trois versions, dans cet ordre.

### Version 1 - Courte (3 a 5 lignes)
Pour un destinataire presse. Le message essentiel et la demande, rien d'autre.

### Version 2 - Complete
Structure : contexte, probleme ou information, demande explicite, prochaine etape.
Phrases courtes. Une idee par phrase. Voix active. Pas de formule creuse.

### Version 3 - Points a verifier
Ce qui manque ou reste ambigu dans le brouillon, sous forme de questions courtes.
Par exemple : "tu ne precises pas la date limite", "on ne sait pas qui doit agir".

## Regles

- Tu ne changes aucun fait, chiffre, nom ou conclusion technique.
- Tu n'ajoutes aucune information absente du brouillon. Si une information manque,
  tu la signales en version 3 au lieu de l'inventer.
- Si le type de texte n'est pas precise, tu pars du principe qu'il s'agit d'un mail interne.
- Tu ecris en francais, registre professionnel simple.
- Tu ne commentes jamais la qualite du brouillon. Tu corriges, c'est tout.

/clarifier-mon-texte mail

bon alors le pipeline il a plante cette nuit vers 3h a cause du schema qui a change
cote source, faut que je previenne l'equipe metier que les chiffres d'hier sont pas
bons et que je repasse le truc ce matin, et aussi demander a l'equipe source de nous
prevenir quand ils changent des trucs

---
name: doc-table
description: Produit la documentation complete d'une table ou d'un modele de donnees a partir du code SQL et des fichiers YAML du depot.
argument-hint: [nom du modele ou chemin du fichier]
allowed-tools: Read, Grep, Glob
---

# Documenter : $0

## Etape 1 - Rassembler

Retrouve dans le depot :
- Le fichier SQL du modele `$0`
- Les fichiers YAML qui le decrivent ou le testent
- Les modeles amont dont il depend
- Les modeles aval qui l'utilisent

Si tu ne trouves pas `$0`, liste les noms approchants et arrete-toi la.

## Etape 2 - Produire la documentation

Ecris exactement cette structure, en francais :

## Role de la table
Deux phrases maximum : a quelle question metier cette table repond.

## Grain
Une ligne represente quoi, exactement ? Precise la cle unique.

## Colonnes

| Colonne | Type | Definition metier | Source | Regle de calcul |
|---|---|---|---|---|

La definition metier est une phrase comprehensible par un non-technicien.
La regle de calcul n'apparait que si la colonne est calculee.

## Filtres appliques
Tout ce qui est exclu, avec la raison. C'est la source numero un des ecarts de chiffres.

## Dependances
Amont : les modeles lus. Aval : ce qui consomme cette table.

## Pieges connus
Duplications possibles, valeurs nulles attendues, changements de perimetre,
colonnes qui ressemblent a une autre sans avoir la meme definition.

## Tests recommandes
Trois tests concrets, au format YAML dbt, prets a coller.

## Regles

- Tu ne decris que ce que le code fait reellement, pas ce qu'il devrait faire.
- Chaque affirmation s'appuie sur un fichier : cite `chemin:ligne`.
- Si une definition metier est absente du code, ecris `[A CONFIRMER AVEC LE METIER]`.
  N'invente jamais une definition.

/doc-table fct_ventes

---
name: revue-sql
description: Relit les fichiers SQL modifies mais non encore commites, et signale les risques avant livraison.
disable-model-invocation: true
allowed-tools: Bash(git diff *), Bash(git status *), Read, Grep
---

# Revue des modifications SQL en cours

## Fichiers modifies

!`git status --short`

## Detail des modifications

!`git diff -- "*.sql"`

## Ta mission

Relis uniquement les modifications ci-dessus, dans cet ordre :

1. **Exactitude** : jointures qui dupliquent des lignes, `LEFT JOIN` annule par un filtre
   dans le `WHERE`, `GROUP BY` incomplet, gestion des `NULL`.
2. **Perimetre** : filtres de date, exclusions (annulations, tests, internes),
   coherence avec les definitions du CLAUDE.md.
3. **Performance** : volume lu, filtre non pousse, fonction appliquee sur une colonne
   de partitionnement.
4. **Conventions du projet** : nommage, `SELECT *` interdit en couche finale, CTE nommees.

Pour chaque point : gravite (BLOQUANT / IMPORTANT / MINEUR), fichier et ligne,
ce qui casse concretement, et le SQL corrige.

Termine par une requete de controle a executer avant livraison
(comptage de lignes, somme d'un montant, comparaison avec la periode precedente).

Si `git diff` ne renvoie rien, dis simplement qu'il n'y a aucune modification SQL en cours.

/revue-sql