J'aurais pu créer un skill générique "bug fix". Un template qui demande le symptôme, le comportement attendu, ce qui a déjà été essayé. Utile. Générique. Oubliable.
À la place, j'ai regardé mon git log. Sur ce projet, 8 commits sur 30 concernent le même sous-système Node.js. Toujours les mêmes patterns : timeout API, slug regex, fichier JSON corrompu. Le skill que j'ai créé ne demande pas le symptôme — il lit directement les 3 fichiers qui expliquent 80% des pannes, dans l'ordre. C'est ça la différence entre un template générique et un skill sur mesure.
Tout est déjà là : quelles tâches reviennent, quels sous-systèmes cassent, quelles séquences sont invariantes. Reste à le lire.
L'audit : ce que ton git log révèle vraiment
Commence par cette commande :
git log --oneline -50 | awk '{$1=""; print $0}' | sed 's/([^)]*)//' | sort | uniq -c | sort -rn | head -20
Ce que tu vois : la fréquence réelle de chaque type de tâche sur les 50 derniers commits. Sur ce portfolio :
8 fix(veille): système de veille Node.js — bugs fréquents, architecture complexe
5 feat(blog): création d'articles — toujours le même ordre de fichiers
3 fix(blog): corrections post-publication — typos, syntaxe PHP, slugs
2 refactor(veille): refactorisations du même sous-système
1 docs(publish): mises à jour workflow
Trois signaux à chercher :
- Fréquence — ce qui revient souvent mérite un skill. Une tâche faite une fois, non.
- Scope répété — toujours les mêmes fichiers modifiés ensemble → le skill sait où regarder.
- Fixes dans le même sous-système — plusieurs
fix(X)→ il y a des points de défaillance connus à encoder.
Complète avec ça pour voir quels fichiers sont le plus souvent touchés ensemble :
git log --oneline -30 --name-only | grep -v "^[a-f0-9]" | sort | uniq -c | sort -rn | head -15
Transformer un pattern en skill
Un skill Claude Code est un fichier markdown dans ~/.claude/plugins/<nom>/skills/<nom>/SKILL.md. La structure minimale :
---
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é]
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. Elle doit répondre à : dans quelles situations exactes ce skill est pertinent ?
Description floue → faux positifs et faux négatifs
# ❌ 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 dernière ligne — "Do NOT trigger for" — est aussi importante que les conditions positives. Elle évite les collisions entre skills similaires.
Exemple concret : les 3 skills générés depuis ce projet
Le git log a identifié 3 patterns clairement distincts. Voici les skills correspondants.
Skill 1 — création d'article (feat(blog) × 5)
Cinq commits, toujours le même ordre de fichiers : PHP FR → PHP EN → posts.json → OG image → php -l → commit → deploy. Un seul oubli (l'entrée posts.json, l'OG image) et le déploiement est cassé.
---
name: blog-article
description: >
Use when asked to create, write, draft or publish a blog article.
Trigger on: "new article", "write about X", "publish on LinkedIn/dev.to",
any mention of blog post creation or article workflow.
---
Ordre d'exécution obligatoire :
1. blog/posts/<slug>.php — version FR complète
2. blog/posts/<slug>.en.php — version EN complète
3. blog/posts.json — entrée FR + EN en première position
4. npm run og <slug> — OG image
5. php -l sur les deux fichiers — vérification syntaxe
6. git commit + push
7. node scripts/publish-article.js <slug> — LinkedIn + dev.to + deploy
Ne jamais sauter une étape. Ne jamais commiter sans php -l.
Ce skill encode 5 itérations d'expérience. Sans lui, chaque création d'article nécessite de relire CLAUDE.publish.md en entier.
Skill 2 — debug veille (fix(veille) × 8)
Huit commits de fix sur le même sous-système. Ça veut dire qu'il y a des points de défaillance récurrents — autant les encoder directement.
---
name: veille-debug
description: >
Use for any bug, error or unexpected behavior in the automated watch/veille system.
Trigger on: veille errors, jobs not running, articles not generated, daemon issues,
Claude API timeouts in watch context, slug/registry problems.
Do NOT trigger for blog PHP bugs or LinkedIn/dev.to publishing issues.
---
Lire dans cet ordre avant tout diagnostic :
1. scripts/veille/registry.json — jobs configurés et leur état
2. logs/veille-daemon.log — dernière exécution (timestamp + erreurs)
3. scripts/veille/runner.js — architecture générale
Points de défaillance connus (par fréquence) :
- Timeout Claude API → augmenter timeout dans la config du job concerné
- Slug regex trop restrictif → tester avec node scripts/veille/test-slug.js
- updates.json corrompu → supprimer le fichier, le système se recrée au prochain run
- Mauvais répertoire de travail cron → vérifier WorkingDirectory dans le .service systemd
- renderArticle() qui n'écrit pas → vérifier que article.json existe et contient les bons champs
Sans ce skill, débugger la veille revient à relire le code depuis zéro. Avec lui, Claude sait où 80% des problèmes se cachent.
Skill 3 — fix post-publication (fix(blog) × 3)
Les corrections post-publication ont leur propre contrainte : ne déployer que les fichiers modifiés (pas un deploy complet qui écrase des données de prod).
---
name: blog-fix
description: >
Use for small fixes on already-published blog articles: typos, grammar,
PHP syntax errors, slug corrections, missing tags.
Trigger after publication, not during creation.
Do NOT trigger for new article creation.
---
Contraintes pour les fixes post-publication :
- Ne jamais lancer scripts/deploy.sh complet
- Utiliser bash scripts/deploy-files.sh <fichier1> <fichier2> (deploy ciblé)
- php -l obligatoire avant tout deploy
- Si posts.json modifié → l'inclure dans deploy-files.sh
Commit convention : fix(blog): <description courte>
Le git log ne suffit pas — l'historique des conversations aussi
Le git log dit quoi a été fait et combien de fois. Il ne dit pas comment c'était demandé, ni ce qui a frictionné dans les échanges avec l'IA. Or c'est souvent là que se cachent les meilleurs skills.
L'historique des conversations révèle :
- Les clarifications que Claude a dû demander à chaque session → information manquante à encoder dans le skill
- Les corrections "non pas comme ça, comme ça" → contraintes à rendre explicites
- Les reformulations répétées → mots-clés exacts pour les trigger conditions
- Ce qu'on a réexpliqué d'une session à l'autre → ce qui devrait être dans le skill, pas dans la tête
En pratique, le texte brut des conversations passées n'est pas stocké. Mais trois sources en capturent l'essentiel :
1. Les fichiers mémoire (feedback)
Chaque correction sauvegardée en mémoire est un signal direct. Sur ce projet, memory/feedback_article_workflow.md contient :
Ne pas passer par brainstorming pour les articles — trop de cérémonie.
Écrire directement dans l'ordre : FR → EN → posts.json → OG → php -l → commit → deploy.
C'est exactement la contrainte principale du skill blog-article. Elle n'est pas dans le code — elle est dans l'historique des corrections. Sans la mémoire, cette règle aurait dû être réexpliquée à chaque session.
2. Le git log du CLAUDE.md lui-même
git log --oneline -- CLAUDE.md .claude/CLAUDE.md
Chaque commit qui modifie un CLAUDE.md est la trace d'une friction qui a forcé une mise à jour de règle. C'est souvent le résultat d'une conversation : quelque chose s'est mal passé, on a ajouté une contrainte. Ces ajouts sont des candidats directs au contenu des skills.
3. Les commits de workflow (docs, chore)
Sur ce projet : docs(publish): add article creation workflow to CLAUDE.publish.md. Ce commit existe parce qu'une session précédente a révélé un gap dans la documentation du workflow. Le contenu ajouté ce jour-là est exactement ce qu'un skill doit encoder.
Combiner les deux sources
| 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, ce qui a frictionné | 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 du skill |
Un skill généré uniquement depuis le git log sait quoi faire. Un skill généré depuis le git log et l'historique des corrections sait quoi faire, et comment ne pas se tromper.
Ce qui fait qu'un skill s'auto-déclenche bien
Après quelques semaines d'utilisation, les patterns qui fonctionnent :
Descriptions courtes avec des mots-clés concrets. "Trigger on: veille errors, jobs not running" marche mieux que "Use when there are problems with the automated system". Les mots-clés correspondent à 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 — et pas toujours le bon. Mieux vaut un skill avec des conditions plus larges qu'un overlap entre deux skills proches.
Encoder les contraintes non-évidentes. "Ne jamais lancer deploy.sh complet pour un fix" est le genre d'information qu'on réapprend à chaque fois si elle n'est pas dans le skill. C'est exactement ce que le skill doit encoder : les décisions qu'on a prises et qu'on ne veut pas reconsidérer à chaque fois.
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 les formulations naturelles que tu utilises dans la description.
Conclusion
Le git log est le meilleur point de départ parce qu'il est honnête. Il montre ce qu'on fait vraiment, pas ce qu'on pense faire. Les tâches fréquentes, les sous-systèmes fragiles, les séquences invariantes — tout est là.
Un skill générique "bug fix" aurait une valeur marginale sur la plupart des projets. Un skill qui connaît les 5 points de défaillance connus de ton système, sait quels fichiers lire en premier, et encode les contraintes spécifiques au projet — c'est un collègue qui a passé du temps sur le code.
La différence entre les deux, c'est 30 minutes passées à lire son git log.