Générer des skills Claude Code depuis le git log

# CLAUDE.md — Générer des skills Claude Code depuis le git log

> Contexte spécialisé pour Claude Code. À utiliser quand on veut auditer son historique git pour identifier les tâches récurrentes et créer des skills sur mesure qui s'auto-déclenchent au bon moment.

---

## Quand utiliser ce contexte

- ✅ Premier setup de skills sur un projet existant
- ✅ Skills qui se déclenchent mal ou trop souvent — recalibrage
- ✅ Après 2-3 mois de travail sur un projet — assez d'historique pour identifier les patterns
- ✅ Onboarding sur un repo : comprendre les points de friction récurrents avant de commencer
- ❌ Créer un skill générique réutilisable sur tous projets — ce contexte cible le sur-mesure projet
- ❌ Documenter l'architecture — appartient au CLAUDE.md, pas aux skills

---

## Section 1 : Audit du git log

### Commande principale

```bash
git log --oneline -50 | awk '{$1=""; print $0}' | sed 's/([^)]*)//' | sort | uniq -c | sort -rn | head -20
```

Résultat : fréquence réelle de chaque type de tâche sur les 50 derniers commits.

### Fichiers touchés ensemble

```bash
git log --oneline -30 --name-only | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -15
```

Les fichiers qui reviennent ensemble → le skill sait où regarder en premier.

### 3 signaux à chercher

```
✅ Fréquence élevée      → une tâche faite 5+ fois mérite un skill
✅ Scope répété          → toujours les mêmes fichiers modifiés ensemble → le skill lit ces fichiers
✅ Fixes récurrents      → plusieurs fix(X) sur le même sous-système → points de défaillance connus à encoder
❌ Tâche ponctuelle      → faite une fois, ne justifie pas un skill
❌ Tâche triviale        → ce qui prend 30 secondes, pas besoin de formaliser
```

---

## Section 2 : Structure d'un skill

### Fichier SKILL.md

```
~/.claude/plugins/<nom-plugin>/skills/<nom-skill>/SKILL.md
```

Structure minimale :

```text
---
name: nom-du-skill
description: >
  [Conditions de déclenchement — c'est ici que tout se joue]
---

[Ce que Claude doit faire quand le skill est déclenché]
```

### Description : pattern de détection

La `description` n'est pas de la documentation — c'est un **pattern de détection**. Claude la lit à chaque message pour décider si le skill s'applique.

```text
# ❌ Trop vague
description: Use when there's a bug.

# ✅ Précis
description: >
  Use for any bug, error or unexpected behavior in the automated watch system (veille).
  Trigger on: "veille doesn't work", "job not running", "article not generated",
  any error in scripts/veille/ or logs/veille-daemon.log.
  Do NOT trigger for blog PHP bugs or deploy issues.
```

**La ligne "Do NOT trigger for"** est aussi importante que les conditions positives — elle évite les collisions entre skills similaires.

### Corps du skill : ce qu'il faut encoder

```
✅ Ordre de lecture des fichiers clés (par fréquence d'implication dans les bugs)
✅ Points de défaillance connus (nommés explicitement)
✅ Séquences invariantes (ne jamais sauter l'étape X)
✅ Contraintes non-évidentes (ce qu'on réapprend à chaque fois)
❌ Ce qui est dans le code — Claude peut le lire
❌ Documentation générale — appartient au CLAUDE.md
```

---

## Section 3 : Sources complémentaires au git log

Le git log dit *quoi* a été fait. Il ne dit pas *comment* c'était demandé ni *ce qui a frictionné*. Trois sources capturent l'essentiel :

### Fichiers mémoire (feedback)

```bash
cat .claude/projects/*/memory/feedback_*.md
```

Chaque correction sauvegardée en mémoire est un signal direct. Si une règle apparaît dans `feedback_X.md`, elle est candidate au contenu d'un skill.

### Git log du CLAUDE.md lui-même

```bash
git log --oneline -- CLAUDE.md .claude/CLAUDE.md
```

Chaque commit qui modifie un CLAUDE.md = une friction qui a forcé une mise à jour de règle. Ces ajouts sont des candidats directs au contenu des skills.

### Commits de workflow (docs, chore)

Les commits `docs(X)` et `chore(X)` révèlent des gaps de documentation découverts en session. Le contenu ajouté ce jour-là est souvent exactement ce qu'un skill doit encoder.

### Tableau récapitulatif

| Source | Ce qu'elle révèle | Utile pour |
|--------|-------------------|------------|
| Git log commits | Tâches fréquentes, fichiers touchés ensemble, sous-systèmes fragiles | Identifier quels skills créer |
| Memory/feedback | Corrections passées, contraintes apprises | Contenu et contraintes du skill |
| Git log CLAUDE.md | Règles ajoutées suite à des frictions | Contraintes non-évidentes à encoder |
| Commits docs/chore | Gaps de documentation révélés en session | Séquences et cas limites |

---

## Section 4 : Ce qui fait qu'un skill s'auto-déclenche bien

```
✅ Mots-clés concrets dans la description
   "Trigger on: veille errors, jobs not running" > "Use when there are problems"
   Les mots-clés doivent correspondre à ce que l'utilisateur écrit naturellement.

✅ Un seul skill par contexte
   Si deux skills peuvent se déclencher sur la même situation, Claude choisit — pas toujours le bon.
   Mieux vaut un skill avec des conditions larges qu'un overlap entre deux skills proches.

✅ Contraintes non-évidentes encodées
   "Ne jamais lancer deploy.sh complet pour un fix" — ce genre de règle doit être dans le skill,
   pas dans la tête. C'est ce qu'on réapprend à chaque fois si ça n'est pas là.

✅ Tester avec des variantes
   Un skill qui se déclenche sur "article" mais pas sur "post de blog" ou "publication LinkedIn"
   est mal calibré. Lister dans la description les formulations naturelles qu'on utilise.
```

---

## Section 5 : Prompt d'audit — appliquer la méthode

À lancer sur un projet existant pour générer les skills depuis zéro.

```text
Audite mon historique git pour identifier les skills Claude Code à créer.

Étape 1 — Analyse du git log :
git log --oneline -50 | awk '{$1=""; print $0}' | sed 's/([^)]*)//' | sort | uniq -c | sort -rn | head -20
git log --oneline -30 --name-only | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -15

Étape 2 — Sources complémentaires :
- Lire les fichiers feedback dans .claude/projects/*/memory/
- git log --oneline -- CLAUDE.md .claude/CLAUDE.md

Étape 3 — Pour chaque pattern identifié (fréquence ≥ 3) :
1. Quel est le contexte de déclenchement exact ?
2. Quels fichiers sont toujours lus/modifiés ?
3. Quelles sont les contraintes non-évidentes (ce qui a merdé ou frictionné) ?
4. Y a-t-il des points de défaillance connus ?

Étape 4 — Proposer un SKILL.md par pattern avec :
- name et description (avec "Do NOT trigger for")
- Corps : ordre de lecture des fichiers + contraintes encodées

Ne pas créer de skills génériques. Chaque skill doit être sur mesure pour ce projet.
```

---

*Last updated: 2026-03 — Contexte associé à l'article [Générer des skills Claude Code depuis ton historique git](https://www.web-developpeur.com/blog/skills-claude-code-git-log).*