zhongwei/gh-jls42-leapmultix-leapmultix-marketplace-leapmultix-dev-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:26:42 +08:00
commit c112387243
15 changed files with 3051 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,18 @@
{
"name": "leapmultix-dev-core",
"description": "Core workflow: code review duo, plugin manager, and CI quality gate skills",
"version": "1.0.0",
"author": {
"name": "Julien LE SAUX",
"email": "contact@jls42.org"
},
"skills": [
"./skills"
],
"agents": [
"./agents"
],
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# leapmultix-dev-core
Core workflow: code review duo, plugin manager, and CI quality gate skills

57
agents/code-reviewer.md Normal file
View File

@@ -0,0 +1,57 @@
---
name: code-reviewer
description: Réviseur de code expert spécialisé en sécurité, performance et bonnes pratiques. À utiliser de manière proactive après des modifications de code.
tools: Read, Grep, Glob, Bash, WebSearch
model: inherit
color: blue
---
Vous êtes un réviseur de code senior d'élite avec plus de 15 ans d'expérience, spécialisé dans les applications web éducatives, les jeux sur canevas, et les PWA. Votre mission est de garantir une qualité de code prête pour la production à travers des revues approfondies et constructives.
## Contexte du projet : leapmultix
- **Architecture** : Modules ES6, `eventBus`, navigation par slides.
- **Pile Technique** : Vanilla JS (ES2022), HTML5 Canvas, Web Audio, Service Workers.
- **Normes Clés** :
- **Sécurité :** Prévention XSS via `security-utils.js`.
- **Performance :** Jeux à 60 FPS, Lighthouse > 90.
- **Accessibilité :** Conformité WCAG 2.1 AA.
- **Qualité :** ESLint (complexité cognitive < 15), couverture de test > 80%.
## Votre Processus de Revue
1. **Comprendre les Changements :** Examine les modifications récentes du code pour comprendre ce qui a changé.
2. **Analyse Multi-axes :** Évaluez le code selon les catégories ci-dessous.
3. **Priorisation :** Classez vos retours en Critiques (bloquants), Importants (à corriger), et Suggestions.
4. **Rapport :** Utilisez le format de sortie standardisé pour présenter vos conclusions.
## Checklist de Revue Essentielle
### 1. Sécurité (Priorité Absolue)
- **Prévention XSS :** L'utilisation de `innerHTML` est-elle évitée au profit des fonctions de `security-utils.js` (`appendSanitizedHTML`, `createSafeElement`) ?
- **Validation :** Toutes les entrées externes (données utilisateur, URL, localStorage) sont-elles validées ?
### 2. Performance
- **Jeux Canvas :** Le code évite-t-il les redessinages inutiles ? `requestAnimationFrame` est-il utilisé correctement ? Les écouteurs et timers sont-ils nettoyés pour éviter les fuites de mémoire ?
- **Général :** Le code utilise-t-il le chargement paresseux (`lazy-loader.js`) ? Les opérations coûteuses sont-elles optimisées (debounce/throttle) ?
### 3. Qualité et Architecture
- **Principes :** Le code respecte-t-il les principes de responsabilité unique et DRY (Don't Repeat Yourself) ?
- **Lisibilité :** Les noms sont-ils clairs ? Les fonctions sont-elles courtes et ciblées ?
- **Architecture :** La communication passe-t-elle bien par `eventBus` pour éviter le couplage fort ? Les nouveaux modules respectent-ils la structure existante ?
### 4. Accessibilité et i18n
- **Accessibilité :** Les éléments sont-ils accessibles au clavier ? Les labels ARIA sont-ils présents et descriptifs ? Les contrastes de couleur sont-ils suffisants ?
- **Internationalisation :** Toutes les chaînes de caractères visibles par l'utilisateur utilisent-elles `getTranslation()` ?
## Format de Sortie Requis (CRITIQUE)
Pour générer votre revue de code, tu DOIS :
1. Lire le fichier `.claude/skills/report-template-code-review.md`.
2. Utiliser son contenu comme template exact pour ta réponse.
3. Remplir chaque section du template avec tes conclusions.

567
agents/plugin-manager.md Normal file
View File

@@ -0,0 +1,567 @@
---
name: plugin-manager
description: Expert for creating and managing Claude Code plugins with marketplace manifests. Use proactively when user wants to create, package, configure, or distribute plugins across projects
tools: Read, Write, Grep, Glob, Bash, WebFetch
model: inherit
---
# Plugin Manager Agent
Vous êtes un expert en création et gestion de plugins Claude Code. Votre mission est d'aider les utilisateurs à empaqueter leurs commands, agents, skills et hooks en plugins réutilisables et distribuables.
## Rôle et Responsabilités
Vous orchestrez la création complète de plugins Claude Code :
- Analyser projets existants pour identifier composants empaquetables
- Créer structure de plugin conforme
- Générer fichiers de configuration (plugin.json, marketplace.json)
- Copier et organiser composants
- Créer documentation (README.md)
- Tester installation locale
- Valider compliance des composants
- Guider la distribution en équipe
## Contexte Projet : leapmultix
Ce projet est une application éducative de mathématiques avec :
- **Skills** : 22 skills dans `.claude/skills/` (arcade, i18n, security, testing, etc.)
- **Agents** : Plusieurs agents spécialisés dans `.claude/agents/`
- **Commands** : Slash commands dans `.claude/commands/`
- **Hooks** : Event handlers dans `.claude/hooks/`
**Architecture :** ES modules, Jest tests, PWA, jeux canvas, i18n (fr/en/es)
## Format de Sortie Requis (CRITIQUE)
Pour toutes les opérations de création de plugin, tu DOIS :
1. **Lire le skill de référence** : `.claude/skills/creating-plugins/SKILL.md`
2. **Utiliser les templates fournis** :
- `.claude/skills/creating-plugins/templates/plugin.json.template`
- `.claude/skills/creating-plugins/templates/marketplace.json.template`
3. **Suivre le workflow exact** décrit dans le skill
4. **Appliquer les checklists** de validation
## Workflow de Création de Plugin
### Phase 1 : Analyse du Projet
**Objectif :** Identifier tous les composants disponibles pour packaging
1. **Examiner les composants existants** :
- Lister tous les skills : `.claude/skills/*/SKILL.md`
- Lister tous les agents : `.claude/agents/*.md`
- Lister toutes les commands : `.claude/commands/*.md`
- Vérifier hooks : `.claude/hooks/hooks.json`
2. **Présenter au user** :
- Afficher liste complète des composants
- Demander quels composants inclure dans le plugin
- Suggérer groupements logiques si pertinent (ex: "arcade games", "testing tools", "i18n tools")
3. **Déterminer metadata** :
- Demander nom du plugin (kebab-case)
- Demander description (claire, max 1024 chars)
- Demander author
- Proposer version initiale (1.0.0)
### Phase 2 : Création de la Structure
**Objectif :** Créer hiérarchie de dossiers conforme
1. **Créer dossiers racine** :
```bash
mkdir plugin-name
mkdir plugin-name/.claude-plugin
```
2. **Créer dossiers pour composants sélectionnés** :
```bash
mkdir -p plugin-name/commands # Si commands sélectionnées
mkdir -p plugin-name/agents # Si agents sélectionnés
mkdir -p plugin-name/skills # Si skills sélectionnées
mkdir -p plugin-name/hooks # Si hooks sélectionnés
```
**RÈGLE ABSOLUE :** Composants vont à la racine du plugin, PAS dans `.claude-plugin/`
### Phase 3 : Génération des Fichiers de Configuration
**Objectif :** Créer plugin.json et marketplace.json valides
1. **Lire les templates** :
- Lire `.claude/skills/creating-plugins/templates/plugin.json.template`
- Lire `.claude/skills/creating-plugins/templates/marketplace.json.template`
2. **Générer plugin.json** :
- Remplacer placeholders avec metadata collectées
- Valider format JSON
- Sauvegarder dans `plugin-name/.claude-plugin/plugin.json`
3. **Générer marketplace.json** (si distribution prévue) :
- Remplacer placeholders
- Valider format JSON
- Sauvegarder dans dossier parent marketplace
**Validation :** Vérifier que :
- Tous les champs requis sont présents (name, description, version, author)
- Version suit semantic versioning (X.Y.Z)
- Name est en kebab-case
- JSON est valide (pas de trailing commas, etc.)
### Phase 4 : Copie des Composants
**Objectif :** Copier composants sélectionnés dans structure plugin
Pour chaque type de composant sélectionné :
**Commands :**
```bash
cp .claude/commands/selected-command.md plugin-name/commands/
```
**Agents :**
```bash
cp .claude/agents/selected-agent.md plugin-name/agents/
```
**Skills :**
```bash
cp -r .claude/skills/selected-skill/ plugin-name/skills/
```
**Hooks :**
```bash
cp .claude/hooks/hooks.json plugin-name/hooks/
```
**IMPORTANT :** Préserver la structure exacte (notamment pour skills avec sous-dossiers)
### Phase 5 : Génération de la Documentation
**Objectif :** Créer README.md complet et utile
Le README doit contenir :
1. **Titre et description** :
```markdown
# Nom du Plugin
Description détaillée expliquant l'utilité du plugin.
```
2. **Installation** :
```markdown
## Installation
\`\`\`bash
/plugin marketplace add ./path/to/marketplace
/plugin install plugin-name@marketplace-name
\`\`\`
```
3. **Composants inclus** :
Liste de tous les commands, agents, skills avec descriptions
4. **Usage et exemples** :
Exemples concrets d'utilisation
5. **Prérequis** :
Dependencies, tools nécessaires
6. **Troubleshooting** :
Solutions aux erreurs courantes
**Template de base :**
```markdown
# {{PLUGIN_NAME}}
{{DESCRIPTION_DETAILLEE}}
## Installation
\`\`\`bash
/plugin marketplace add ./{{MARKETPLACE_PATH}}
/plugin install {{PLUGIN_NAME}}@{{MARKETPLACE_NAME}}
\`\`\`
## Composants inclus
### Commands
{{LISTE_COMMANDS_AVEC_DESCRIPTIONS}}
### Agents
{{LISTE_AGENTS_AVEC_DESCRIPTIONS}}
### Skills
{{LISTE_SKILLS_AVEC_DESCRIPTIONS}}
## Usage
{{EXEMPLES_CONCRETS}}
## Prérequis
{{LISTE_PREREQUIS}}
## Troubleshooting
{{SOLUTIONS_ERREURS}}
```
### Phase 6 : Création du Marketplace LeapMultix
**Objectif :** Permettre test local avant distribution
1. **Créer la structure du marketplace** :
```bash
mkdir -p leapmultix-marketplace/.claude-plugin
mv plugin-name leapmultix-marketplace/
```
2. **Créer marketplace.json** :
- Utiliser template
- Référencer le plugin
- Sauvegarder dans `leapmultix-marketplace/.claude-plugin/marketplace.json`
3. **Structure finale** :
```
leapmultix-marketplace/
├── .claude-plugin/
│ └── marketplace.json
└── plugin-name/
├── .claude-plugin/
│ └── plugin.json
├── commands/
├── agents/
├── skills/
└── README.md
```
### Phase 6 bis : Synchronisation LeapMultix (CRITIQUE)
**Objectif :** Générer automatiquement tous les plugins (bundle + unitaires) via `npm run plugin:sync`.
1. **Mettre à jour les profils** dans `leapmultix-marketplace/plugin-profiles.json` (target, listes commands/agents/skills, description, category).
2. **Exécuter le script** :
```bash
npm run plugin:sync -- --profile=all,core,audit
# Bundle personnalisé si besoin
npm run plugin:sync -- --target=leapmultix-marketplace/custom-bundle \
--agents=code-reviewer --skills=checking-code-quality --commands=audit-config
```
3. **Résultats automatiques** :
- Copie des composants depuis `.claude/`
- Regénération des `plugin.json`
- Création des plugins unitaires (`leapmultix-agent-*`, `leapmultix-skill-*`, `leapmultix-command-*`)
- Mise à jour des manifests marketplace (`.claude-plugin/marketplace.json` + `leapmultix-marketplace/.claude-plugin/marketplace.json`)
⚠️ **Ne jamais** installer/tester un plugin tant que `npm run plugin:sync` n'a pas été relancé après les dernières modifications.
### Phase 7 : Test et Validation
**Objectif :** Vérifier que le plugin fonctionne correctement
1. **Installer localement** :
```bash
/plugin marketplace add ./leapmultix-marketplace
/plugin install plugin-name@leapmultix-marketplace
```
2. **Vérifications de base** :
- Exécuter `/help` → commands apparaissent ?
- Tester une command → fonctionne ?
- Invoquer un agent → répond ?
- Skills détectés automatiquement ?
3. **Validation compliance** :
- Utiliser skill `checking-config-compliance`
- Vérifier frontmatter des agents
- Vérifier structure des skills
- S'assurer noms en kebab-case
4. **Checklist finale** :
- Lire checklist dans `.claude/skills/creating-plugins/SKILL.md` section "Checklist avant publication"
- Vérifier chaque point
- Corriger si nécessaire
### Phase 8 : Distribution (Optionnel)
**Objectif :** Préparer pour distribution en équipe
1. **Configuration équipe** :
- Créer ou mettre à jour `.claude/settings.json`
- Ajouter marketplace path
- Ajouter plugin avec enabled: true
2. **Documentation finale** :
- Mettre à jour README avec instructions spécifiques équipe
- Documenter prérequis
- Expliquer workflow de mise à jour
3. **Notifier équipe** :
- Créer annonce avec instructions
- Expliquer bénéfices du plugin
- Fournir support pour questions
## Principes de Conception
### "Teach WHAT, not HOW"
❌ **Mauvais** (trop prescriptif) :
```bash
find .claude/skills -name "SKILL.md"
```
✅ **Bon** (objectif clair) :
- Examine tous les skills disponibles dans `.claude/skills/`
- Identifie leurs noms et descriptions
- Présente la liste au user
### Code Vivant comme Source de Vérité
**TOUJOURS** lire les fichiers du projet pour :
- Comprendre structure exacte
- Vérifier frontmatter des composants
- S'assurer de la conformité actuelle
- Adapter aux patterns existants
**JAMAIS** copier du code obsolète ou faire des suppositions sur la structure.
### Utilisation du Skill de Référence
**À CHAQUE opération** de création de plugin :
1. Lire `.claude/skills/creating-plugins/SKILL.md`
2. Suivre workflow exact décrit
3. Utiliser templates fournis
4. Appliquer checklists de validation
Le skill contient **toutes les règles et formats** nécessaires. Ne pas réinventer, réutiliser !
## Gestion des Erreurs
### Erreur : Components not found
**Diagnostic :**
- Vérifier que `.claude/` existe
- Lister contenu de `.claude/skills/`, `.claude/agents/`, etc.
**Solution :**
- Afficher message clair au user
- Proposer d'examiner structure du projet
- Suggérer création de composants si vide
### Erreur : Invalid JSON in plugin.json
**Diagnostic :**
- Vérifier format JSON (trailing commas, quotes, etc.)
- Valider champs requis présents
**Solution :**
- Corriger JSON automatiquement
- Valider avec outil (bash jq si disponible)
- Afficher JSON final au user pour confirmation
### Erreur : Plugin installation fails
**Diagnostic :**
- Vérifier structure dossiers (composants à racine, pas dans .claude-plugin/)
- Vérifier plugin.json valide
- Vérifier marketplace.json référence correcte
**Solution :**
- Examiner structure créée
- Corriger erreurs de structure
- Réessayer installation
### Erreur : Commands not appearing after install
**Diagnostic :**
- Vérifier plugin est enabled (`/plugin` pour vérifier)
- Vérifier commands dans bon dossier (`plugin-name/commands/`)
- Vérifier pas de conflits de noms
**Solution :**
- Activer plugin si désactivé
- Corriger structure si nécessaire
- Renommer commands si conflit
## Cas d'Usage Courants
### Use Case 1 : Transformer projet actuel en plugin
**Scénario :** User veut partager tous les outils leapmultix comme plugin
**Actions :**
1. Lister TOUS les composants (22 skills, agents, commands)
2. Proposer plugin complet ou groupements thématiques
3. Créer structure pour sélection user
4. Générer avec metadata appropriées
5. Tester localement
6. Valider compliance
### Use Case 2 : Créer plugin thématique
**Scénario :** User veut plugin uniquement pour outils arcade games
**Actions :**
1. Filtrer composants : skills arcade-related, agents arcade-specialist
2. Créer plugin "arcade-tools"
3. Documentation focalisée sur jeux canvas
4. Tests spécifiques aux jeux
### Use Case 3 : Update plugin existant
**Scénario :** User veut ajouter nouveaux composants à plugin
**Actions :**
1. Examiner plugin existant (structure, version)
2. Identifier nouveaux composants
3. Copier dans plugin
4. Incrémenter version (suivre semantic versioning)
5. Mettre à jour README
6. Documenter changements
7. Tester cycle complet (uninstall → reinstall)
### Use Case 4 : Créer marketplace multi-plugins
**Scénario :** User veut marketplace avec plusieurs plugins thématiques
**Actions :**
1. Créer plusieurs plugins (arcade, testing, i18n, etc.)
2. Créer dossier marketplace parent
3. Placer tous les plugins dedans
4. Créer marketplace.json référençant tous
5. Tester installation de chaque plugin
## Checklist d'Auto-Validation
Avant de présenter le plugin au user, vérifier :
**Structure :**
- [ ] `.claude-plugin/plugin.json` existe
- [ ] Composants à racine du plugin (pas dans .claude-plugin/)
- [ ] README.md présent et complet
**Configuration :**
- [ ] plugin.json valide (JSON correct, champs requis)
- [ ] version suit semantic versioning
- [ ] name en kebab-case
- [ ] description claire (< 1024 chars)
**Composants :**
- [ ] Tous les composants sélectionnés copiés
- [ ] Structure préservée (notamment skills avec sous-dossiers)
- [ ] Pas de fichiers sensibles (.env, secrets)
**Documentation :**
- [ ] README explique installation
- [ ] README liste tous les composants
- [ ] README fournit exemples d'usage
- [ ] Prérequis documentés
**Tests :**
- [ ] Plugin installable localement
- [ ] Commands apparaissent dans /help
- [ ] Agents fonctionnels
- [ ] Skills détectés
## En Cas de Doute
**Sources de vérité (ordre de consultation) :**
1. `.claude/BEST_PRACTICES_AGENTS_SKILLS.md` section Plugins
2. `.claude/skills/creating-plugins/SKILL.md` pour workflow détaillé
3. Documentation officielle via WebFetch si ambiguïté :
```
WebFetch(url: "https://code.claude.com/docs/en/plugins",
prompt: "Clarifier [aspect spécifique]")
```
4. Code existant dans `.claude/` pour patterns concrets
**Règles absolues (JAMAIS violer) :**
1. Composants TOUJOURS à racine du plugin (commands/, agents/, skills/)
2. `.claude-plugin/` contient UNIQUEMENT plugin.json (et éventuellement marketplace.json)
3. TOUJOURS valider JSON avant sauvegarde
4. TOUJOURS tester installation locale avant distribution
5. TOUJOURS utiliser semantic versioning
6. JAMAIS inclure secrets ou credentials
7. TOUJOURS lire le skill `creating-plugins` avant opérations
**Workflow minimal (cas simple) :**
```bash
# 1. Analyser composants disponibles
# 2. Créer structure
mkdir plugin-name/.claude-plugin
mkdir plugin-name/commands
# 3. Générer plugin.json (utiliser template)
# 4. Copier composants sélectionnés
# 5. Créer README
# 6. Créer marketplace de test
# 7. Installer localement et tester
# 8. Valider compliance
```
## Interaction avec le User
### Toujours :
- Expliquer chaque étape avant exécution
- Présenter choix clairs (quels composants inclure)
- Afficher résultats après chaque phase
- Demander confirmation avant actions irréversibles
- Fournir instructions pour prochaines étapes
### Jamais :
- Créer plugin sans input du user sur composants
- Supposer metadata (toujours demander name, author, etc.)
- Installer/désinstaller sans avertir
- Ignorer erreurs de validation
### Communication :
- Utiliser langage clair et concis
- Structurer output (listes, sections)
- Fournir exemples quand utile
- Anticiper questions courantes

40
commands/audit-config.md Normal file
View File

@@ -0,0 +1,40 @@
---
description: Audits Skills, Subagents or Slash Commands for compliance with best practices
---
# Audit de Conformité
Utilisez l'agent-architecte pour auditer la conformité des composants de configuration.
## Arguments
- `skills` - Auditer tous les Skills
- `agents` ou `subagents` - Auditer tous les Subagents
- `commands` ou `slash` - Auditer tous les Slash Commands
- `all` - Auditer tous les composants
- `[nom-composant]` - Auditer un composant spécifique
## Exemples
```bash
/audit-config skills # Audite tous les skills
/audit-config agents # Audite tous les agents
/audit-config all # Audit complet
/audit-config accessibility # Audite le skill accessibility
```
---
Je vais maintenant utiliser l'agent-architecte pour auditer : **$ARGUMENTS**
Utilise l'agent `agent-architecte` avec le workflow Mode 2 (Audit de Composants Existants) pour :
1. Identifier les composants concernés ($ARGUMENTS)
2. Auditer chaque composant avec les checklists de `config-compliance-checker`
3. Générer un rapport consolidé avec :
- Scores de conformité
- Problèmes classés par criticité (🔴🟡🔵)
- Top corrections prioritaires
- Diffs proposés pour corrections
Le rapport doit être structuré et exploitable pour améliorer la qualité des configurations.

89
plugin.lock.json Normal file
View File

@@ -0,0 +1,89 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:jls42/leapmultix:leapmultix-marketplace/leapmultix-dev-core",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "e6419ed92f76ecc33400722a7f24a63a0416f2eb",
"treeHash": "356c92bfd715381107687c06b5d27c3b9171939403c63626463baf0f17e654ef",
"generatedAt": "2025-11-28T10:19:10.411948Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "leapmultix-dev-core",
"description": "Core workflow: code review duo, plugin manager, and CI quality gate skills",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "ff6710b210db6c82f582bd88b533376be7b69654e8f79dd04a2731a9b65ad10c"
},
{
"path": "agents/code-reviewer.md",
"sha256": "0b26f20be6adc4f6d19e4f17b48e859821ddf757dd23b1e265f16251177e7f19"
},
{
"path": "agents/plugin-manager.md",
"sha256": "9156645775cc76de82e5e6468464ed21f570d922f143d9085ae809a3ff94053b"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "25a6db553dd2105e0e8735c397be3e7a66e5209944b432cc7e51221e5a2ca6ae"
},
{
"path": "commands/audit-config.md",
"sha256": "129beda55e91e48f1680d8af6babe3a6c857de396ad2316606b68a5180972e43"
},
{
"path": "skills/checking-config-compliance/SKILL.md",
"sha256": "145bab0d321c9345ffb44a78601b062bb2d0d14742332d4cd477f225cdc8c29b"
},
{
"path": "skills/checking-config-compliance/reference/validation-patterns.md",
"sha256": "29c9015b720281c36ba695a6eab4bb7f9dc39be1c7193652a32fc1c7f2de2bf3"
},
{
"path": "skills/checking-code-quality/SKILL.md",
"sha256": "e2e581186b4c663fc3de80b04d0d4641356708fd096d6486c5518f3a9be4f864"
},
{
"path": "skills/running-quality-gate/SKILL.md",
"sha256": "6e5f19bc6eb2698159939c93a6bd63d4a2d665a7dfc64d2f60b7f8835ed78c97"
},
{
"path": "skills/creating-plugins/SKILL.md",
"sha256": "67ef7d8ba50a586de9d1bc24072357b5cb98da90035198c37ccfc14a98a7fec2"
},
{
"path": "skills/creating-plugins/templates/plugin.json.template",
"sha256": "d0c8738c329f09b6960330d3394d3bde989465585200aef430a43de13a46621d"
},
{
"path": "skills/creating-plugins/templates/marketplace.json.template",
"sha256": "6720d62fe85bca77b583c9e71eddf3d453f4aaba14e72b1848311b7135342d8e"
},
{
"path": "skills/creating-pull-requests/SKILL.md",
"sha256": "f17a8bcc223d570a852f352be91964691d1c15853dd12f7fa11befe1a36f0a84"
},
{
"path": "skills/helping-with-commits/SKILL.md",
"sha256": "a6a01d1893f6a8ca2c457fb5ebf80f38b43c8af7cf59a9441e1971fb21549a73"
}
],
"dirSha256": "356c92bfd715381107687c06b5d27c3b9171939403c63626463baf0f17e654ef"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

145
skills/checking-code-quality/SKILL.md Normal file
View File

@@ -0,0 +1,145 @@
---
name: checking-code-quality
description: Executes code quality checks (format:check, ESLint, Jest) before each commit according to leapmultix project standards
allowed-tools: Read, Grep, Glob, Bash
---
# Code Quality Gate
Garantit code respecte standards avant commit (format, lint, tests).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Workflow OBLIGATOIRE (séquence)](#workflow-obligatoire-séquence)
- [Standards essentiels](#standards-essentiels)
- [ESLint suppressions](#eslint-suppressions)
- [Scripts disponibles](#scripts-disponibles)
- [Configuration](#configuration)
- [Conventions commit](#conventions-commit)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- **TOUJOURS** avant chaque commit
- Avant créer PR
- Après modification JavaScript/CSS
- À la demande
## Workflow OBLIGATOIRE (séquence)
1. **Formatage (CRITIQUE) :**
```bash
npm run format:check
# Si ✗ → npm run format
```
2. **Linting :**
```bash
npm run lint
# Si ✗ → npm run lint:fix
```
3. **Tests :**
```bash
npm test
```
4. **Couverture (recommandé) :**
```bash
npm run test:coverage
```
**Ou tout-en-un :** `npm run verify` (lint + test + coverage)
## Standards essentiels
**JavaScript :**
- Pas variables inutilisées (supprime ou eslint-disable avec justification)
- Pas catch blocks vides (logger erreur)
- Utiliser security-utils pour DOM (`appendSanitizedHTML()`, `setSafeMessage()`)
- Complexité cognitive < 15 (découpe fonctions complexes)
**CSS :**
- Notation couleur moderne : `rgb(255 255 255 / 0.9)` pas `rgba(...)`
**Sécurité :**
- Jamais `innerHTML` données externes (utiliser security-utils)
- Scripts externes: `crossorigin="anonymous"`
- Integrity hashes bibliothèques (pas analytics, auto-update)
- Valider entrées externes
## ESLint suppressions
**Ligne :** `// eslint-disable-next-line rule -- Justification`
**Bloc :** `/* eslint-disable rule */ ... /* eslint-enable rule */`
**Règle :** Toujours justifier avec `--` pourquoi sécurisé/intentionnel.
## Scripts disponibles
- `npm test` - Tests
- `npm run test:watch` - Mode watch
- `npm run test:coverage` - Couverture
- `npm run verify:dead-code` - Code mort
- `npm run analyze:*` - Globals, jsdoc, dependencies
## Configuration
- `eslint.config.js` - Règles ESLint
- `.prettierrc` - Formatage
- `.stylelintrc.json` - CSS
- `jest.config.cjs` - Tests
## Conventions commit
- Impératif : "Fix", "Add", "Refactor"
- Concis, descriptif
- Jamais mentionner AI/assistants
## Checklist
- [ ] format:check passe
- [ ] lint passe
- [ ] tests passent
- [ ] coverage acceptable
- [ ] Pas console.log oubliés
- [ ] Pas variables inutilisées
- [ ] security-utils pour DOM
- [ ] Message descriptif
- [ ] Pas secrets/API keys
## En cas de doute
**Règles absolues :**
1. `npm run format:check` TOUJOURS d'abord
2. Ne JAMAIS committer si échec
3. Ne JAMAIS désactiver sans justification
4. Exécuter localement AVANT pusher
**Workflow minimal :**
```bash
npm run format:check && npm run lint && npm test
```
**Workflow complet :**
```bash
npm run verify
```
**Fichiers clés :**
- CLAUDE.md - Conventions
- eslint.config.js - Règles
- security-utils.js - DOM sécurisé

416
skills/checking-config-compliance/SKILL.md Normal file
View File

@@ -0,0 +1,416 @@
---
name: checking-config-compliance
description: Validates configuration compliance for Skills, Subagents and Slash Commands against best practices. Use proactively when creating or auditing configuration files.
allowed-tools: Read, Grep, Glob, WebSearch
---
# Config Compliance Checker
Valide la conformité des Skills, Subagents et Slash Commands selon les bonnes pratiques définies dans `BEST_PRACTICES_AGENTS_SKILLS.md`.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Sources de vérité](#sources-de-vérité)
- [Checklist : Skills](#checklist--skills)
- [Checklist : Subagents](#checklist--subagents)
- [Format de Sortie Requis (CRITIQUE)](#format-de-sortie-requis-critique)
- [Checklist : Slash Commands](#checklist--slash-commands)
- [Patterns de validation](#patterns-de-validation)
- [Rapport d'audit](#rapport-daudit)
- [Workflow d'audit complet](#workflow-daudit-complet)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Création d'un nouveau Skill/Subagent/Slash Command
- Audit des configurations existantes
- Avant commit de modifications de config
- Review de PR touchant `.claude/`
## Sources de vérité
**Document de référence principal :** `.claude/BEST_PRACTICES_AGENTS_SKILLS.md`
Ce skill fournit des checklists concrètes pour valider la conformité.
### Consultation de la Documentation Officielle
En cas de doute sur une règle de conformité ou une spécification exacte, consultez la documentation officielle listée dans `BEST_PRACTICES_AGENTS_SKILLS.md` via WebSearch.
**Cas d'usage pour WebSearch :**
- ✅ Vérifier les limites exactes (max 64 chars pour name, max 1024 pour description)
- ✅ Valider une règle de nommage spécifique (gérondif, kebab-case)
- ✅ Confirmer la syntaxe YAML frontmatter
- ✅ Découvrir de nouvelles best practices non encore documentées dans BEST_PRACTICES
**Ne PAS utiliser pour :**
- ❌ Remplacer la lecture de BEST_PRACTICES (toujours lire en premier)
- ❌ Copier du contenu verbatim (résumer et adapter au contexte du projet)
---
## Checklist : Skills
### 1. Frontmatter YAML
**✅ Requis :**
```yaml
---
name: skill-name
description: What it does and when to use it
---
```
**Validations :**
- [ ] `name` : kebab-case, sans guillemets, forme gérondif recommandée (-ing)
- [ ] `description` : 3ème personne, < 1024 chars, sans guillemets
- [ ] `allowed-tools` (optionnel) : liste séparée par virgules
**❌ Erreurs communes :**
```yaml
# MAUVAIS
name: "Validateur d'Accessibilité" # Guillemets inutiles, pas kebab-case
name: helper # Nom vague
description: I process files # 1ère personne
# BON
name: processing-pdfs
description: Processes PDF files and extracts structured data. Use for document automation.
```
### 2. Structure de fichier
**Recommandé :**
```
skill-name/
├── SKILL.md # < 500 lignes
├── reference/ # Fichiers de référence
│ └── patterns.md
└── scripts/ # Scripts utilitaires
└── validator.py
```
**Validations :**
- [ ] SKILL.md < 500 lignes
- [ ] Références à un niveau de profondeur max
- [ ] Scripts utilisent forward slashes (`/`)
### 3. Contenu
**Validations :**
- [ ] Focalisé sur une seule tâche
- [ ] Pas de copie de code (référence au code vivant)
- [ ] Tables des matières si > 100 lignes
- [ ] Exemples concrets (input/output)
---
## Checklist : Subagents
### 1. Frontmatter YAML
**✅ Requis :**
```yaml
---
name: agent-name
description: Expert role and when to use it
tools: Read, Write, Bash
model: inherit
---
```
**Validations :**
- [ ] `name` : kebab-case, sans guillemets
- [ ] `description` : 3ème personne, inclut "quand utiliser", mots comme "proactivement"
- [ ] `tools` : explicitement définis (principe du moindre privilège)
- [ ] `model` : `inherit` recommandé ou alias (sonnet, opus, haiku)
**❌ Erreurs communes :**
```yaml
# MAUVAIS
name: "Code Reviewer" # Guillemets inutiles, espace
tools: * # Trop permissif
description: Reviews code # Manque "quand"
# BON
name: code-reviewer
tools: Read, Grep, Glob, Bash, WebSearch
description: Expert code reviewer specializing in security and performance. Use proactively after code modifications.
model: inherit
```
### 2. Prompt système
**Validations :**
- [ ] Persona clairement définie ("Vous êtes un expert en...")
- [ ] Contexte clé du projet fourni
- [ ] Principes et workflows décrits
- [ ] Référence au code vivant
- [ ] Intégration de skills explicite si applicable
**Exemple d'intégration skill :**
```markdown
## Format de Sortie Requis (CRITIQUE)
Pour générer votre rapport, vous DEVEZ :
1. Lire le fichier `.claude/skills/report-template/SKILL.md`
2. Utiliser son contenu comme template exact
```
---
## Checklist : Slash Commands
### 1. Structure de fichier
**Localisation :**
- Personal : `~/.claude/commands/`
- Project : `.claude/commands/` (versionné)
**Format :**
```markdown
---
description: Brief description of what it does
---
Prompt content here with optional $ARGUMENTS
```
**Validations :**
- [ ] Nom fichier : kebab-case.md
- [ ] `description` claire et concise
- [ ] Arguments gérés avec `$ARGUMENTS` ou `$1`, `$2`
- [ ] Documentation du comportement
**Exemple :**
```markdown
---
description: Review code for security issues
---
Review the following code: $ARGUMENTS
Focus on:
- Security vulnerabilities
- Best practices violations
```
---
## Patterns de validation
### Validation du nom (kebab-case)
**Regex :** `^[a-z0-9]+(-[a-z0-9]+)*$`
**✅ Valides :**
- `processing-pdfs`
- `code-reviewer`
- `practicing-tdd-with-jest`
**❌ Invalides :**
- `ProcessingPDFs` (PascalCase)
- `processing_pdfs` (snake_case)
- `"processing-pdfs"` (guillemets)
- `processing pdfs` (espace)
### Validation de la description (3ème personne)
**Patterns ✅ :**
- "Processes PDF files..."
- "Validates configuration..."
- "Expert reviewer specializing in..."
**Patterns ❌ :**
- "I process files..." (1ère personne)
- "Process files..." (impératif)
- "" (vide)
### Validation allowed-tools vs tools
**Skills :**
```yaml
allowed-tools: Read, Grep # Avec tiret
```
**Subagents :**
```yaml
tools: Read, Write, Bash # Sans tiret
```
---
## Rapport d'audit
### Format recommandé
```markdown
# Audit de Conformité : [nom-du-composant]
**Type :** Skill | Subagent | Slash Command
**Fichier :** `.claude/.../nom.md`
**Date :** YYYY-MM-DD
## Score global : [X]/10
## Conformité Frontmatter
- [ ] ✅/❌ Nom conforme (kebab-case, gérondif pour skills)
- [ ] ✅/❌ Description conforme (3ème personne, < 1024 chars)
- [ ] ✅/❌ Tools/allowed-tools correctement défini
- [ ] ✅/❌ Model spécifié (subagents)
## Conformité Contenu
- [ ] ✅/❌ Structure de fichier appropriée
- [ ] ✅/❌ Taille < 500 lignes (skills)
- [ ] ✅/❌ Références au code vivant
- [ ] ✅/❌ Exemples concrets présents
## Problèmes détectés
### 🔴 Critiques
- Description non conforme
### 🟡 Avertissements
- Taille légèrement élevée (520 lignes)
### 🔵 Suggestions
- Ajouter exemples concrets
## Actions recommandées
1. Corriger le nom : `"Code Reviewer"` → `code-reviewer`
2. Réécrire description en 3ème personne
3. Définir explicitement les tools
## Diff proposé
\`\`\`diff
- name: "Code Reviewer"
* name: code-reviewer
- description: Reviews code
* description: Expert code reviewer specializing in security. Use proactively after modifications.
\`\`\`
```
---
## Workflow d'audit complet
### 1. Identifier les composants
```bash
# Skills
find .claude/skills -name "SKILL.md"
# Subagents
find .claude/agents -name "*.md"
# Slash Commands
find .claude/commands -name "*.md"
```
### 2. Auditer chaque composant
Pour chaque fichier :
1. Lire le frontmatter YAML
2. Valider chaque champ avec la checklist
3. Analyser le contenu
4. Générer le rapport
### 3. Prioriser les corrections
**🔴 Critiques (bloquer) :**
- Nom non conforme (empêche découverte)
- Description invalide
- Syntaxe YAML incorrecte
**🟡 Avertissements (corriger bientôt) :**
- Taille > 500 lignes
- Manque exemples
- Tools trop permissifs
**🔵 Suggestions (amélioration) :**
- Ajouter tables des matières
- Améliorer organisation
- Ajouter tests
### 4. Générer rapport consolidé
```markdown
# Rapport d'Audit Global
**Date :** YYYY-MM-DD
**Composants audités :** X skills, Y agents, Z commands
## Scores moyens
- Skills : 7.5/10
- Subagents : 8.2/10
- Slash Commands : 9.0/10
## Résumé des problèmes
- 🔴 Critiques : 3
- 🟡 Avertissements : 8
- 🔵 Suggestions : 12
## Top 5 corrections prioritaires
1. [skill-name] : Corriger nom et description
2. [agent-name] : Définir tools explicitement
...
```
---
## En cas de doute
**Règles absolues :**
1. Toujours consulter `.claude/BEST_PRACTICES_AGENTS_SKILLS.md`
2. Toujours valider kebab-case pour les noms
3. Toujours vérifier 3ème personne pour descriptions
4. Toujours appliquer principe du moindre privilège (tools)
**Documentation officielle :**
Consultez les liens dans `BEST_PRACTICES_AGENTS_SKILLS.md` pour les spécifications exhaustives.

508
skills/checking-config-compliance/reference/validation-patterns.md Normal file
View File

@@ -0,0 +1,508 @@
# Patterns de Validation Détaillés
Ce document contient des patterns de validation spécifiques et des exemples pour auditer Skills, Subagents et Slash Commands.
## Table des matières
- [Validation des Noms](#validation-des-noms)
- [Validation des Descriptions](#validation-des-descriptions)
- [Validation YAML](#validation-yaml)
- [Exemples Complets](#exemples-complets)
---
## Validation des Noms
### Skills : Forme Gérondif Recommandée
**Pattern :** `[verb]-ing-[context]` ou `[action]-ing-[subject]`
**✅ Excellents exemples :**
- `processing-pdfs` - Verbe + objet
- `analyzing-spreadsheets` - Verbe + objet
- `validating-accessibility` - Verbe + concept
- `managing-dependencies` - Verbe + objet
**✅ Acceptables (pas gérondif mais clairs) :**
- `report-template-code-review` - Template clairement identifié
- `quality-checklist` - Concept établi compréhensible
- `tdd-red-green` - Acronyme + méthodologie
**❌ À corriger :**
- `helper` - Trop vague
- `utils` - Trop générique
- `tool` - Non descriptif
- `accessibility-validator` - Préférer `validating-accessibility`
### Subagents : Rôle Clair
**Pattern :** `[role]-[specialization]` ou `[domain]-[specialist]`
**✅ Excellents exemples :**
- `code-reviewer` - Rôle clair
- `performance-analyzer` - Rôle + domaine
- `pwa-expert` - Domaine + expertise
- `accessibility-auditor` - Domaine + rôle
**❌ À corriger :**
- `helper-agent` - Trop vague
- `ai-assistant` - Trop générique
- `tool` - Non descriptif
### Regex de Validation
```regex
# Kebab-case strict
^[a-z0-9]+(-[a-z0-9]+)*$
# Kebab-case sans nombres (recommandé)
^[a-z]+(-[a-z]+)*$
# Validation guillemets (doit échouer)
^["'].*["']$
```
---
## Validation des Descriptions
### Skills : 3ème Personne + Quand
**Structure recommandée :**
```
[Verb]s [object] and [action]. Use for/when [context].
```
**✅ Excellents exemples :**
```
Processes PDF files and extracts structured data. Use for document automation.
Analyzes bundle size and identifies optimization opportunities. Use before releases or when bundle exceeds 200KB.
Validates accessibility compliance against WCAG 2.1 AA. Use when modifying UI or before major releases.
```
**❌ À corriger :**
```
# 1ère personne
I process PDF files → Processes PDF files
# Impératif
Process PDF files → Processes PDF files
# Manque contexte d'usage
Processes PDFs → Processes PDFs. Use for document automation.
# Trop vague
Helps with files → Processes PDF files and extracts data. Use for automation.
```
### Subagents : 3ème Personne + Quand + Proactivement
**Structure recommandée :**
```
Expert [role] specializing in [domain]. Use [proactively] [when/after/before] [context].
```
**✅ Excellents exemples :**
```
Expert code reviewer specializing in security and performance. Use proactively after code modifications.
PWA specialist for service workers and offline functionality. Use for PWA modifications or before production audits.
Performance analyst for web applications and canvas games. Use proactively for performance issues or before releases.
```
**❌ À corriger :**
```
# Manque "proactivement"
Reviews code for security → Expert reviewer. Use proactively after modifications.
# Manque contexte "quand"
Expert in accessibility → Expert auditor. Use proactively after UI changes.
# 1ère personne
I review code → Expert reviewer specializing in security.
```
### Validation de Longueur
```
Max 1024 caractères
Recommandé : 100-300 caractères pour clarté
```
---
## Validation YAML
### Frontmatter Skills
**✅ Format correct :**
```yaml
---
name: processing-pdfs
description: Processes PDF files and extracts structured data. Use for document automation.
allowed-tools: Read, Grep, Bash
---
```
**❌ Erreurs courantes :**
```yaml
---
# Guillemets inutiles
name: "processing-pdfs"
name: 'processing-pdfs'
# Espace au lieu de tiret
name: processing pdfs
# PascalCase
name: ProcessingPDFs
# Field incorrect pour Skills
tools: Read, Write # Devrait être allowed-tools
# Description vide
description:
description: ""
---
```
### Frontmatter Subagents
**✅ Format correct :**
```yaml
---
name: code-reviewer
description: Expert code reviewer specializing in security. Use proactively after modifications.
tools: Read, Grep, Glob, Bash, WebSearch
model: inherit
---
```
**❌ Erreurs courantes :**
```yaml
---
# Guillemets inutiles
name: 'code-reviewer'
# Tools non définis (hérite de tout)
# Manque l'application du principe du moindre privilège
# Model non spécifié (perte de cohérence)
# Devrait avoir model: inherit
# Field incorrect pour Subagents
allowed-tools: Read # Devrait être tools (sans tiret)
---
```
### Frontmatter Slash Commands
**✅ Format correct :**
```yaml
---
description: Review code for security and performance issues
tools: Read, Grep, Glob
model: sonnet
---
```
**❌ Erreurs courantes :**
```yaml
---
# name n'est pas nécessaire (nom = nom du fichier)
name: review-code
# Description trop vague
description: Reviews code
---
```
---
## Exemples Complets
### Skill Conforme (Excellent)
**Fichier :** `.claude/skills/processing-invoices/SKILL.md`
```yaml
---
name: processing-invoices
description: Processes invoice PDFs, extracts line items and validates totals. Use for accounting automation.
allowed-tools: Read, Bash
---
# Invoice Processor
Automates invoice processing with validation.
## Quand utiliser
- Traitement de factures PDF
- Extraction de données structurées
- Validation de totaux
## Workflow
1. Lire PDF avec script
2. Extraire données
3. Valider totaux
4. Générer rapport JSON
[... < 500 lignes ...]
```
**Score : 10/10**
### Skill Non Conforme (Nécessite Corrections)
**Fichier :** `.claude/skills/helper/SKILL.md`
```yaml
---
name: 'Helper Tool'
description: Helps with various tasks
---
# Helper
I help you with stuff.
[... contenu vague ...]
```
**Problèmes :**
- ❌ Nom : guillemets, espace, trop vague
- ❌ Description : vague, pas 3ème personne, manque contexte
- ❌ Contenu : 1ère personne, pas focalisé
**Corrections proposées :**
```yaml
---
name: processing-contracts
description: Processes contract documents and extracts key terms. Use for legal document automation.
allowed-tools: Read, Grep
---
# Contract Processor
Automates contract analysis and term extraction.
## Quand utiliser
- Analyse de contrats PDF
- Extraction de clauses clés
- Génération de résumés
[... contenu focalisé ...]
```
**Score après corrections : 9/10**
### Subagent Conforme (Excellent)
**Fichier :** `.claude/agents/security-auditor.md`
```yaml
---
name: security-auditor
description: Expert security auditor specializing in web vulnerabilities and OWASP Top 10. Use proactively before releases or after security-critical changes.
tools: Read, Grep, Glob, Bash, WebSearch
model: inherit
---
Vous êtes un expert en sécurité web avec une connaissance approfondie de OWASP Top 10.
## Mission
Auditer le code pour détecter :
- Vulnérabilités XSS
- Injections SQL
- Failles CSRF
- Dépendances vulnérables
## Workflow
1. Analyser security-utils.js pour patterns
2. Chercher innerHTML avec données externes
3. Vérifier sanitization
4. Auditer dépendances avec npm audit
5. Générer rapport avec score
## Format de Sortie
Pour générer votre rapport, vous DEVEZ :
1. Lire `.claude/skills/security-report-template/SKILL.md`
2. Utiliser son contenu comme template exact
```
**Score : 10/10**
### Subagent Non Conforme (Nécessite Corrections)
**Fichier :** `.claude/agents/helper.md`
```yaml
---
name: 'Code Helper'
description: Helps with code
---
I help you write code.
```
**Problèmes :**
- ❌ Nom : guillemets, espace, vague
- ❌ Description : vague, manque "quand", pas "proactivement"
- ❌ Tools : non définis (trop permissif)
- ❌ Model : non spécifié
- ❌ Contenu : 1ère personne, pas de persona claire
**Corrections proposées :**
```yaml
---
name: code-refactoring-specialist
description: Expert code refactoring specialist for maintainability and performance. Use proactively after adding features or when complexity increases.
tools: Read, Write, Edit, Grep, Glob, Bash
model: inherit
---
Vous êtes un expert en refactoring avec une maîtrise des design patterns.
## Mission
Améliorer la maintenabilité du code :
- Réduire complexité cognitive
- Extraire fonctions réutilisables
- Appliquer SOLID principles
- Optimiser performances
## Workflow
1. Analyser le code existant
2. Identifier les code smells
3. Proposer refactoring patterns
4. Appliquer changements
5. Vérifier que tests passent
## Principes
- Ne jamais casser les tests existants
- Refactorer par petites étapes
- Toujours tester après chaque modification
```
**Score après corrections : 9/10**
---
## Checklist Validation Rapide
### Pour Skills
```
✓ Nom kebab-case sans guillemets
✓ Nom forme gérondif (-ing) recommandée
✓ Description 3ème personne < 1024 chars
✓ Description inclut "Use for/when"
✓ Field: allowed-tools (avec tiret)
✓ SKILL.md < 500 lignes
✓ Pas de copie de code
```
### Pour Subagents
```
✓ Nom kebab-case sans guillemets
✓ Description 3ème personne < 1024 chars
✓ Description inclut "quand" et "proactivement"
✓ Field: tools (sans tiret)
✓ Tools explicitement définis
✓ Model spécifié (inherit recommandé)
✓ Persona claire
✓ Workflow décrit
```
### Pour Slash Commands
```
✓ Nom fichier kebab-case.md
✓ Description claire
✓ Arguments avec $ARGUMENTS
✓ Documentation du comportement
```
---
## Scores de Conformité
### Échelle de notation
**10/10 - Excellent**
- Tous les critères respectés
- Exemples concrets présents
- Documentation complète
**8-9/10 - Très bien**
- Tous critères majeurs respectés
- Quelques suggestions mineures
**6-7/10 - Acceptable**
- Critères majeurs respectés
- Plusieurs avertissements
**4-5/10 - Nécessite corrections**
- Quelques critères critiques non respectés
- Nombreux avertissements
**0-3/10 - Non conforme**
- Plusieurs critères critiques non respectés
- Corrections urgentes nécessaires
### Pondération des critères
**Critiques (bloquer) - 40% :**
- Nom conforme (kebab-case)
- Description conforme (3ème personne)
- Syntaxe YAML correcte
**Importants - 40% :**
- Tools correctement définis
- Contenu focalisé
- Structure appropriée
**Suggestions - 20% :**
- Exemples présents
- Documentation complète
- Optimisations

713
skills/creating-plugins/SKILL.md Normal file
View File

@@ -0,0 +1,713 @@
---
name: creating-plugins
description: Guides creation of Claude Code plugins with marketplace manifests for packaging and distributing commands, agents, skills and hooks. Use when user wants to create, package or share plugins
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Plugin Creator
Guide la création de plugins Claude Code pour empaqueter et distribuer commands, agents, skills et hooks.
## Table des matières
- [Quand utiliser ce Skill](#quand-utiliser-ce-skill)
- [Prérequis](#prérequis)
- [Structure d'un plugin](#structure-dun-plugin)
- [Workflow de création](#workflow-de-création)
- [Fichiers requis](#fichiers-requis)
- [Commandes de gestion](#commandes-de-gestion)
- [Test local et validation](#test-local-et-validation)
- [Distribution en équipe](#distribution-en-équipe)
- [Exemples concrets](#exemples-concrets)
- [Gestion erreurs](#gestion-erreurs)
- [Checklist avant publication](#checklist-avant-publication)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser ce Skill
- Quand l'utilisateur demande de "créer un plugin", "create a plugin"
- Empaqueter fonctionnalités réutilisables entre projets
- Distribuer commands/agents/skills à une équipe
- Partager des outils avec la communauté
- Transformer un projet existant en plugin
## Prérequis
**Claude Code installé et configuré**
Vérifie : `/help` fonctionne et affiche les commands disponibles
**Projet avec composants à empaqueter**
Au moins un de :
- `.claude/commands/*.md` - Slash commands
- `.claude/agents/*.md` - Subagents
- `.claude/skills/*/SKILL.md` - Skills
- `.claude/hooks/hooks.json` - Event hooks
## Structure d'un plugin
```
plugin-name/
├── .claude-plugin/
│ ├── plugin.json # Manifest du plugin (REQUIS)
│ └── marketplace.json # Manifest marketplace (optionnel, pour distribution)
├── commands/ # Slash commands (copier depuis .claude/commands/)
│ ├── command1.md
│ └── command2.md
├── agents/ # Subagents (copier depuis .claude/agents/)
│ ├── agent1.md
│ └── agent2.md
├── skills/ # Skills (copier depuis .claude/skills/)
│ ├── skill1/
│ │ ├── SKILL.md
│ │ └── templates/
│ └── skill2/
│ └── SKILL.md
├── hooks/ # Event hooks (copier depuis .claude/hooks/)
│ └── hooks.json
└── README.md # Documentation (FORTEMENT RECOMMANDÉ)
```
**IMPORTANT :** Les composants sont à la **racine** du plugin, pas dans `.claude-plugin/` !
## Workflow de création
### 1. Analyser le projet source
Identifie tous les composants à inclure dans le plugin :
- Liste commands : Examine `.claude/commands/`
- Liste agents : Examine `.claude/agents/`
- Liste skills : Examine `.claude/skills/`
- Liste hooks : Examine `.claude/hooks/hooks.json`
Décide quels composants empaqueter (tous ou sous-ensemble).
### 2. Créer la structure du plugin
```bash
# Créer dossier racine du plugin
mkdir plugin-name
# Créer sous-dossier .claude-plugin
mkdir plugin-name/.claude-plugin
# Créer dossiers pour composants (selon besoin)
mkdir -p plugin-name/commands
mkdir -p plugin-name/agents
mkdir -p plugin-name/skills
mkdir -p plugin-name/hooks
```
### 3. Copier les composants
**Commands :**
```bash
cp .claude/commands/*.md plugin-name/commands/
```
**Agents :**
```bash
cp .claude/agents/*.md plugin-name/agents/
```
**Skills :**
```bash
cp -r .claude/skills/* plugin-name/skills/
```
**Hooks :**
```bash
cp .claude/hooks/hooks.json plugin-name/hooks/
```
### 4. Créer plugin.json
Utilise le template `templates/plugin.json.template` :
```json
{
"name": "nom-du-plugin",
"description": "Description claire et concise du plugin",
"version": "1.0.0",
"author": "Julien LE SAUX <contact@jls42.org>"
}
```
Sauvegarde dans `plugin-name/.claude-plugin/plugin.json`
**Règles de nommage :**
- `name` : kebab-case, descriptif
- `description` : Max 1024 caractères, décrit QUOI et QUAND utiliser
- `version` : Semantic versioning (MAJOR.MINOR.PATCH)
- `author` : Toujours `Julien LE SAUX <contact@jls42.org>` (contact officiel du projet)
### 5. Créer README.md
Structure recommandée :
```markdown
# Nom du Plugin
Description détaillée du plugin et de son utilité.
## Installation
\`\`\`bash
/plugin marketplace add ./path/to/marketplace
/plugin install plugin-name@marketplace-name
\`\`\`
## Composants inclus
### Commands
- `/command1` - Description
- `/command2` - Description
### Agents
- `agent1` - Description et quand l'utiliser
- `agent2` - Description et quand l'utiliser
### Skills
- `skill1` - Description
- `skill2` - Description
## Usage
[Exemples d'utilisation concrets]
## Prérequis
[Dépendances, tools nécessaires]
## Troubleshooting
[Solutions aux erreurs courantes]
```
### 6. (Optionnel) Créer marketplace de test
Pour tester et distribuer :
```bash
# Créer dossier marketplace parent
mkdir mon-marketplace
# Déplacer le plugin dedans
mv plugin-name mon-marketplace/
# Créer marketplace.json à la racine
```
Contenu de `mon-marketplace/marketplace.json` :
```json
{
"name": "mon-marketplace",
"owner": "organisation-ou-username",
"plugins": [
{
"name": "plugin-name",
"source": "./plugin-name",
"description": "Description du plugin"
}
]
}
```
### 7. Tester localement
```bash
# Ajouter le marketplace
/plugin marketplace add ./mon-marketplace
# Installer le plugin
/plugin install plugin-name@mon-marketplace
# Vérifier installation
/help
```
Vérifie que :
- Commands apparaissent dans `/help`
- Agents sont disponibles
- Skills sont détectés automatiquement
- Hooks s'exécutent correctement
### Workflow automatisé LeapMultix (CRITIQUE)
Ce repository dispose d'un pipeline de packaging automatique. **Ne pas copier les fichiers à la main**, utilise le script suivant :
1. **Définir les profils** dans `leapmultix-marketplace/plugin-profiles.json`
- `target` → dossier plugin (ex. `leapmultix-marketplace/leapmultix-dev-core`)
- `commands` / `agents` / `skills` → listes (ou `"*"`)
- `description`, `category` → affichage marketplace
2. **Exécuter la synchro** :
```bash
npm run plugin:sync -- --profile=all,core,audit
# Bundle personnalisé
npm run plugin:sync -- --target=leapmultix-marketplace/custom-bundle \
--agents=code-reviewer --skills=checking-code-quality --commands=audit-config
```
3. **Résultat automatique** :
- Copie des composants depuis `.claude/`
- Regénération des `plugin.json`
- Création des plugins unitaires (`leapmultix-agent-*`, `leapmultix-skill-*`, `leapmultix-command-*`)
- Mise à jour des manifests marketplaces (`.claude-plugin/marketplace.json` + `leapmultix-marketplace/.claude-plugin/marketplace.json`)
✅ **À faire systématiquement** : après toute modification d'un command/agent/skill, relancer `npm run plugin:sync` puis réinstaller le plugin concerné dans Claude pour tester la nouvelle version.
## Fichiers requis
### plugin.json (REQUIS)
Localisation : `.claude-plugin/plugin.json`
Champs obligatoires :
- `name` (string) : Identifiant unique du plugin
- `description` (string) : Description claire
- `version` (string) : Version semantic (ex: "1.0.0")
- `author` (string) : Toujours `Julien LE SAUX <contact@jls42.org>`
Champs optionnels :
- `homepage` (string) : URL du projet
- `repository` (string) : URL du repository git
- `license` (string) : Type de licence (MIT, Apache, etc.)
Exemple complet :
```json
{
"name": "mon-plugin-awesome",
"description": "Plugin pour automatiser les workflows de développement avec Claude Code",
"version": "1.2.3",
"author": "Julien LE SAUX <contact@jls42.org>",
"homepage": "https://github.com/jls42/leapmultix",
"repository": "https://github.com/jls42/leapmultix.git",
"license": "AGPL-3.0-or-later"
}
```
### marketplace.json (Optionnel, pour distribution)
Localisation : Racine du marketplace (niveau parent des plugins)
Structure :
```json
{
"name": "marketplace-name",
"owner": "organisation",
"plugins": [
{
"name": "plugin1",
"source": "./plugin1",
"description": "Description courte"
},
{
"name": "plugin2",
"source": "./plugin2",
"description": "Description courte"
}
]
}
```
**Notes :**
- Un marketplace peut contenir plusieurs plugins
- `source` : chemin relatif depuis marketplace.json
- `name` dans marketplace doit matcher `name` dans plugin.json
## Commandes de gestion
### Installation et activation
```bash
# Ajouter un marketplace
/plugin marketplace add <path>
# Exemple : /plugin marketplace add ./mon-marketplace
# Exemple : /plugin marketplace add https://github.com/user/marketplace
# Lister marketplaces enregistrés
/plugin marketplace list
# Installer un plugin
/plugin install <name>@<marketplace>
# Exemple : /plugin install mon-plugin@mon-marketplace
# Activer un plugin désactivé (sans réinstaller)
/plugin enable <name>@<marketplace>
# Désactiver temporairement (sans supprimer)
/plugin disable <name>@<marketplace>
# Désinstaller complètement
/plugin uninstall <name>@<marketplace>
```
### Gestion et debug
```bash
# Menu interactif de gestion
/plugin
# Lister commands installées
/help
# Vérifier version d'un plugin
# (lire .claude-plugin/plugin.json du plugin installé)
```
## Test local et validation
### Workflow de test itératif
1. **Modifier plugin**
- Éditer composants (commands, agents, skills)
- Mettre à jour version dans plugin.json
2. **Réinstaller**
```bash
/plugin uninstall plugin-name@marketplace-name
/plugin install plugin-name@marketplace-name
```
3. **Valider**
- Vérifier avec `/help` que les commands apparaissent
- Tester chaque command individuellement
- Tester agents sur tâches réelles
- Vérifier skills sont découverts automatiquement
- Tester hooks (si applicable)
4. **Valider compliance**
Utilise le skill `checking-config-compliance` pour valider :
- Frontmatter des agents corrects
- Noms en kebab-case
- Descriptions complètes
- Structure des skills conforme
### Checklist de test
- [ ] Plugin installe sans erreur
- [ ] Toutes les commands apparaissent dans `/help`
- [ ] Commands s'exécutent correctement avec arguments
- [ ] Agents sont invoqués automatiquement quand approprié
- [ ] Skills sont découverts par contexte
- [ ] Hooks s'exécutent aux bons moments
- [ ] Pas de conflits avec autres plugins
- [ ] Documentation README claire et complète
## Distribution en équipe
### Configuration automatique via .claude/settings.json
Pour déploiement automatique quand équipe trust le repository :
```json
{
"marketplaces": [
{
"path": "./marketplaces/team-plugins"
}
],
"plugins": [
{
"name": "team-workflow",
"marketplace": "team-marketplace",
"enabled": true
},
{
"name": "project-helpers",
"marketplace": "team-marketplace",
"enabled": true
}
]
}
```
**Workflow équipe :**
1. Créer marketplace dans repository (ex: `./marketplaces/team-plugins/`)
2. Ajouter plugins au marketplace
3. Configurer `.claude/settings.json` dans repository
4. Commiter et pusher
5. Membres équipe : trust le repository
6. Claude Code installe automatiquement les plugins
### Versioning et updates
**Semantic Versioning :**
- **MAJOR** (1.0.0 → 2.0.0) : Breaking changes
- **MINOR** (1.0.0 → 1.1.0) : Nouvelles fonctionnalités rétro-compatibles
- **PATCH** (1.0.0 → 1.0.1) : Bug fixes
**Workflow de mise à jour :**
1. Modifier plugin et incrémenter version dans plugin.json
2. Documenter changements dans README/CHANGELOG
3. Si breaking changes : documenter migration dans README
4. Tester complètement
5. Notifier équipe des updates
6. Équipe désinstalle/réinstalle pour obtenir nouvelle version
## Exemples concrets
### Exemple 1 : Plugin simple (1 command)
```
code-review-plugin/
├── .claude-plugin/
│ └── plugin.json
├── commands/
│ └── review.md
└── README.md
```
`plugin.json` :
```json
{
"name": "code-review",
"description": "Command pour reviews de code automatisées",
"version": "1.0.0",
"author": "Julien LE SAUX <contact@jls42.org>"
}
```
### Exemple 2 : Plugin complet (commands + agents + skills)
```
dev-workflow-plugin/
├── .claude-plugin/
│ └── plugin.json
├── commands/
│ ├── test.md
│ ├── deploy.md
│ └── lint.md
├── agents/
│ ├── code-reviewer.md
│ └── test-writer.md
├── skills/
│ ├── checking-code-quality/
│ │ └── SKILL.md
│ └── creating-pull-requests/
│ └── SKILL.md
└── README.md
```
### Exemple 3 : Marketplace avec multiple plugins
```
company-marketplace/
├── marketplace.json
├── security-tools/
│ ├── .claude-plugin/
│ │ └── plugin.json
│ ├── commands/
│ └── README.md
├── testing-tools/
│ ├── .claude-plugin/
│ │ └── plugin.json
│ ├── agents/
│ └── README.md
└── documentation-tools/
├── .claude-plugin/
│ └── plugin.json
├── skills/
└── README.md
```
`marketplace.json` :
```json
{
"name": "company-tools",
"owner": "MyCompany",
"plugins": [
{
"name": "security-tools",
"source": "./security-tools",
"description": "Outils de sécurité et audit"
},
{
"name": "testing-tools",
"source": "./testing-tools",
"description": "Agents et commands pour TDD"
},
{
"name": "documentation-tools",
"source": "./documentation-tools",
"description": "Génération automatique de docs"
}
]
}
```
## Gestion erreurs
### Erreur : Plugin not found
**Cause :** Nom plugin ou marketplace incorrect
**Solution :**
```bash
/plugin marketplace list # Vérifier nom marketplace
# Vérifier que name dans plugin.json match la commande install
```
### Erreur : Invalid plugin.json
**Cause :** JSON malformé ou champs manquants
**Solution :**
- Valider JSON avec un linter
- Vérifier champs requis : name, description, version, author
- Vérifier format semantic versioning pour version
### Erreur : Commands not appearing in /help
**Causes possibles :**
- Plugin désactivé
- Commands dans mauvais dossier (doivent être dans `plugin-name/commands/` pas `.claude-plugin/commands/`)
- Conflits de noms avec autres plugins
**Solution :**
```bash
/plugin enable plugin-name@marketplace-name
# Vérifier structure : commands/ à la racine du plugin
# Renommer commands si conflit
```
### Erreur : Marketplace not accessible
**Cause :** Path incorrect ou permissions
**Solution :**
- Vérifier path est correct (relatif ou absolu)
- Vérifier permissions de lecture sur dossier
- Pour URLs : vérifier connectivité réseau
### Erreur : Plugin installation fails silently
**Cause :** Composants invalides (agents avec mauvais frontmatter, etc.)
**Solution :**
- Valider chaque composant individuellement avant packaging
- Utiliser skill `checking-config-compliance`
- Vérifier logs Claude Code pour détails
## Checklist avant publication
### Structure et fichiers
- [ ] `.claude-plugin/plugin.json` existe et est valide
- [ ] `plugin.json` contient : name, description, version, author
- [ ] Version suit semantic versioning
- [ ] README.md complet avec installation et usage
- [ ] Composants dans bons dossiers (racine, pas dans .claude-plugin/)
- [ ] Pas de fichiers sensibles (secrets, .env, credentials)
### Validation composants
- [ ] Commands testés individuellement
- [ ] Agents avec frontmatter valide (name, description, tools)
- [ ] Skills avec SKILL.md et structure correcte
- [ ] Hooks testés (si applicable)
- [ ] Compliance validée avec skill `checking-config-compliance`
### Documentation
- [ ] README explique clairement utilité du plugin
- [ ] Instructions d'installation claires
- [ ] Exemples d'utilisation fournis
- [ ] Prérequis documentés (dependencies, tools)
- [ ] Troubleshooting pour erreurs communes
- [ ] Breaking changes documentés (si updates)
### Testing
- [ ] Testé cycle complet : uninstall → install → test
- [ ] Testé sur projet réel
- [ ] Testé par au moins une autre personne
- [ ] Pas de conflits avec plugins courants
- [ ] Performance acceptable (pas de ralentissement)
### Distribution (si applicable)
- [ ] marketplace.json créé et valide
- [ ] Plugin référencé dans marketplace.json
- [ ] Marketplace accessible (local ou remote)
- [ ] `.claude/settings.json` configuré pour équipe
- [ ] Équipe notifiée de la disponibilité
## En cas de doute
**Source :** `.claude/BEST_PRACTICES_AGENTS_SKILLS.md` section Plugins
**Templates disponibles :**
- `templates/plugin.json.template` - Structure plugin.json
- `templates/marketplace.json.template` - Structure marketplace.json
**Règles absolues :**
1. **TOUJOURS** créer plugin.json dans `.claude-plugin/`
2. **TOUJOURS** placer composants à la racine (commands/, agents/, skills/)
3. **JAMAIS** commiter secrets ou credentials
4. **TOUJOURS** versionner avec semantic versioning
5. **TOUJOURS** tester avant distribution équipe
**Workflow minimal :**
```bash
# 1. Créer structure
mkdir plugin-name/.claude-plugin
mkdir plugin-name/commands
# 2. Créer plugin.json
# (utiliser template)
# 3. Copier composants
cp .claude/commands/*.md plugin-name/commands/
# 4. Créer README.md
# 5. Tester localement
mkdir marketplace && mv plugin-name marketplace/
# Créer marketplace.json
/plugin marketplace add ./marketplace
/plugin install plugin-name@marketplace
/help # Vérifier commands
# 6. Valider compliance
# (utiliser skill checking-config-compliance)
```
**Ressources :**
- Documentation officielle : https://code.claude.com/docs/en/plugins
- BEST_PRACTICES section Plugins
- Exemples dans ce SKILL.md

11
skills/creating-plugins/templates/marketplace.json.template Normal file
View File

@@ -0,0 +1,11 @@
{
"name": "{{MARKETPLACE_NAME}}",
"owner": "{{OWNER}}",
"plugins": [
{
"name": "{{PLUGIN_NAME}}",
"source": "./{{PLUGIN_NAME}}",
"description": "{{PLUGIN_DESCRIPTION}}"
}
]
}

9
skills/creating-plugins/templates/plugin.json.template Normal file
View File

@@ -0,0 +1,9 @@
{
"name": "{{PLUGIN_NAME}}",
"description": "{{PLUGIN_DESCRIPTION}}",
"version": "{{VERSION}}",
"author": "{{AUTHOR}}",
"homepage": "{{HOMEPAGE_URL}}",
"repository": "{{REPOSITORY_URL}}",
"license": "{{LICENSE}}"
}

163
skills/creating-pull-requests/SKILL.md Normal file
View File

@@ -0,0 +1,163 @@
---
name: creating-pull-requests
description: Creates GitHub Pull Requests with detailed descriptions generated from commits. Use when user wants to create a PR after committing changes
allowed-tools: Read, Grep, Glob, Bash
---
# PR Creator
Automatise la création de Pull Requests GitHub avec descriptions structurées.
## Table des matières
- [Quand utiliser ce Skill](#quand-utiliser-ce-skill)
- [Prérequis](#prérequis)
- [Workflow de création](#workflow-de-création)
- [Exemples de PR](#exemples-de-pr)
- [Gestion erreurs](#gestion-erreurs)
- [Checklist avant PR](#checklist-avant-pr)
- [Scripts npm utiles](#scripts-npm-utiles)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser ce Skill
- Quand l'utilisateur demande de "create a PR", "créer une PR"
- Après commits sur feature branch
- Feature terminée et prête pour review
## Prérequis
**GitHub CLI (gh) installé et configuré**
Vérifie : `gh --version` et `gh auth status`
## Workflow de création
### 1. Vérifier état branche
- Branche actuelle (pas main)
- Branche pushed vers remote
- Commits présents depuis main
### 2. Analyser les commits
Examine TOUS commits depuis main :
```bash
git log main...HEAD --oneline
git diff main...HEAD --stat
```
Identifie :
- Types (feat/fix/refactor/test/chore)
- Scopes (arcade/i18n/ui/pwa)
- Fichiers modifiés par catégorie
### 3. Générer titre PR
**Règles :**
- 1 commit → utilise message commit
- Similaires → généralise
- Mixte → "Multiple improvements (scopes)"
- Max 72 caractères
### 4. Générer description PR
**Structure :**
```markdown
## Summary
[1-4 bullet points changements clés]
## Changes
[Fichiers modifiés groupés par catégorie]
## Test Plan
- [ ] [Tests spécifiques]
- [ ] Run `npm run verify`
```
**Catégories :** arcade/, components/, core/, i18n/, tests/
### 5. Générer test plan basé sur fichiers
- Arcade → Test jeux, 60 FPS
- i18n → Test langues, `npm run i18n:compare`
- Tests → Coverage ≥ 80%
- Toujours → `npm run verify`, no console errors
### 6. Créer PR avec gh CLI
```bash
gh pr create \
--base main \
--title "type(scope): description" \
--body "$(cat <<'EOF'
## Summary
- Point 1
## Test Plan
- [ ] npm run verify
EOF
)"
```
**Options :** `--draft`, `--label`, `--reviewer`, `--assignee`, `--web`
## Exemples de PR
**1 commit feat :** `feat(arcade): implement power-up system`
**Multiple feat :** Généralise en titre synthétique
**Mixte (feat+fix+refactor) :** `Multiple improvements (arcade, ui)`
## Gestion erreurs
- Branche pas pushed → `git push -u origin $(git branch --show-current)`
- gh non auth → `gh auth login`
- PR existe → `gh pr edit` au lieu de create
- Sur main → Créer feature branch d'abord
## Checklist avant PR
- [ ] `npm run verify` passe
- [ ] `npm run i18n:compare` si i18n modifié
- [ ] Commits suivent Conventional Commits
- [ ] Branche pushed
- [ ] Pas secrets/keys
- [ ] Pas sur main
## Scripts npm utiles
```bash
npm run verify # Quality gate
npm run i18n:compare # Si i18n
git log main...HEAD # Commits
gh pr list # PRs existantes
```
## En cas de doute
**Source :** CLAUDE.md et PRs existantes (`gh pr list --state all`)
**Règles absolues :**
1. Vérifier qualité avant PR (`npm run verify`)
2. Analyser TOUS commits depuis main
3. Jamais PR depuis main
4. Jamais PR si tests échouent
5. Jamais mentionner AI
**Workflow minimal :**
```bash
npm run verify
git push -u origin $(git branch --show-current)
gh pr create --base main --title "..." --body "..."
```

196
skills/helping-with-commits/SKILL.md Normal file
View File

@@ -0,0 +1,196 @@
---
name: helping-with-commits
description: Automates Git commit creation with conventional messages. Use when user wants to commit changes with automatic diff analysis
allowed-tools: Read, Grep, Glob, Bash
---
# Commit Helper
Automatise la création de commits Git avec messages conformes Conventional Commits.
## Table des matières
- [Quand utiliser ce Skill](#quand-utiliser-ce-skill)
- [Convention Conventional Commits](#convention-conventional-commits)
- [Workflow de création](#workflow-de-création)
- [Exemples](#exemples)
- [Cas d'usage](#cas-dusage)
- [Gestion erreurs](#gestion-erreurs)
- [Checklist avant commit](#checklist-avant-commit)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser ce Skill
- Utilisateur demande de "commit" ou "committer"
- Après feature, fix, ou refactoring terminé
- Avant de créer une Pull Request
## Convention Conventional Commits
### Format
```
<type>(<scope>): <description>
```
**Types :** feat, fix, refactor, perf, test, docs, style, chore, ci
**Scopes leapmultix :** arcade, i18n, ui, a11y, perf, pwa, test, deps
**Description :**
- Verbe impératif minuscule (add, fix, update, remove)
- Pas de majuscule, pas de point
- Max 72 caractères
- Spécifique (pas "update code")
## Workflow de création
### 1. Analyser état Git
```bash
git status
git diff --staged
git diff
git log --oneline -5 # Style existant
```
### 2. Déterminer type et scope
**Type :**
- Nouveaux fichiers/fonctions → feat
- Corrections bugs → fix
- Restructuration → refactor
- Tests uniquement → test
- package.json → chore(deps)
**Scope :**
- Examine chemins fichiers
- Identifie domaine principal
- Omets si générique/multiple
### 3. Générer description
- Verbe impératif minuscule
- QUOI pas COMMENT
- Spécifique < 72 chars
### 4. Valider qualité
```bash
npm run format:check # Si échec → format
npm run lint # Si échec → lint:fix
npm test
npm run i18n:compare # Si i18n modifié
```
### 5. Créer commit
```bash
git add <files>
git commit -m "type(scope): description"
```
**Avec body si nécessaire :**
```bash
git commit -m "$(cat <<'EOF'
type(scope): description
Optional body explaining details.
EOF
)"
```
## Exemples
**Bons :**
```
feat(arcade): add power-up system to Multimiam
fix(arcade): correct collision detection
refactor(arcade): extract rendering logic
chore(deps): update jest to 29.7.0
feat(i18n): add Spanish translations
```
**Mauvais :**
```
fix: bug fixes # Trop vague
Add new feature # Pas de type
feat: added feature # Pas impératif
```
## Cas d'usage
### Multiples fichiers, même feature
Un seul commit avec tous les fichiers.
### Multiples types (feat + fix + refactor)
Créer PLUSIEURS commits séparés. Chaque commit = 1 objectif.
### i18n modifié
```bash
npm run i18n:compare # Vérifie sync
# Puis commit
```
### Dépendances
```bash
chore(deps): add playwright
chore(deps): update jest to 29.7.0
fix(deps): update minimatch (CVE-2022-3517)
```
## Gestion erreurs
### Tests échouent
NE PAS committer ! Fix d'abord ou WIP avec `--no-verify` (précaution).
### Lint/Format échoue
```bash
npm run lint:fix
npm run format
git add .
# Puis commit
```
## Checklist avant commit
- [ ] Type correct (feat/fix/refactor/test/chore/docs/style/perf/ci)
- [ ] Scope pertinent (ou vide)
- [ ] Description impérative < 72 chars
- [ ] `npm run format:check` passe
- [ ] `npm run lint` passe
- [ ] `npm test` passe
- [ ] `npm run i18n:compare` si i18n
- [ ] Pas secrets/keys
## En cas de doute
**Source :** CLAUDE.md et `git log` (exemples)
**Règles absolues :**
1. Vérifier qualité avant commit
2. Conventional Commits obligatoire
3. Jamais commit si tests échouent (sauf WIP)
4. Jamais secrets/keys
5. Jamais mentionner l'IA (pas de 'Generated with Claude' ou 'Co-Authored-By: Claude')
**Workflow :**
```bash
npm run verify
git add <files>
git commit -m "type(scope): description"
```

116
skills/running-quality-gate/SKILL.md Normal file
View File

@@ -0,0 +1,116 @@
---
name: running-quality-gate
description: Executes all quality checks (format, lint, tests, i18n, coverage). Use before commits, PRs, or releases to ensure quality standards
allowed-tools: Read, Grep, Glob, Bash
---
# Porte de Qualité
Exécute vérifications de qualité pour garantir standards avant commit/merge/release.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Standards obligatoires](#standards-obligatoires)
- [Scripts npm](#scripts-npm)
- [Workflow séquentiel](#workflow-séquentiel)
- [Gestion des échecs](#gestion-des-échecs)
- [Checklist avant commit](#checklist-avant-commit)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant créer commit
- Avant créer PR
- Avant merger vers main
- Avant release
- En CI/CD pipeline
## Standards obligatoires
**MUST PASS :**
1. Formatage code (Prettier)
2. Linting (ESLint)
3. Tests unitaires (Jest)
4. Couverture ≥ 80% (Branches, Functions, Lines, Statements)
5. i18n synchronisé (fr.json, en.json, es.json)
**Recommandés :**
- Pas d'erreurs console
- Dead code vérifié
- Audit sécurité (`npm audit`)
## Scripts npm
Trouve et utilise :
- `npm run format:check` - Vérifier formatage
- `npm run format` - Formater automatiquement
- `npm run lint` - Linter
- `npm run lint:fix` - Auto-fix linting
- `npm test` ou `npm run verify` - Tests + coverage
- `npm run i18n:compare` - Synchronisation traductions
- `npm run dead-code` - Détection code mort
## Workflow séquentiel
1. **Format :** `npm run format:check`
- Si ✗ : `npm run format` → commit changements
2. **Lint :** `npm run lint`
- Si ✗ : `npm run lint:fix` ou corrige manuellement
3. **Tests :** `npm test`
- Si ✗ : Identifier/corriger test échoué
4. **Coverage :** Vérifier rapport (≥ 80%)
- Si < 80% : Ajouter tests manquants
5. **i18n :** `npm run i18n:compare`
- Si désynchronisé : Ajouter clés manquantes
6. **Optionnels :** dead-code, audit
**Total : < 2 min**
## Gestion des échecs
| Problème | Solution |
| ----------------- | ------------------------- |
| Format échoue | `npm run format` → commit |
| Lint auto-fixable | `npm run lint:fix` |
| Tests échouent | Debug test, corriger code |
| Coverage < 80% | Ajouter tests critiques |
| i18n désyncé | Ajouter clés manquantes |
## Checklist avant commit
- [ ] format:check ✅
- [ ] lint ✅
- [ ] tests ✅ (pas de .skip)
- [ ] coverage ≥ 80%
- [ ] i18n synchronisé
- [ ] console clean (pas de console.log)
- [ ] Code logiquement correct
- [ ] Commit message descriptif
## En cas de doute
**Règles absolues :**
1. Lancer TOUS les scripts avant commit
2. Ne JAMAIS bypass vérifications
3. Corriger erreurs une par une
4. Re-lancer quality gate jusqu'à 100% pass
5. CI/CD doit être vert avant merge
**Exécution rapide :**
```bash
npm run format:check && npm run lint && npm test
```
**Références :**
- Scripts npm (package.json)
- ESLint config (eslint.config.js)
- Prettier config (.prettierrc)
- Jest config (jest.config.cjs)
- CI/CD (.gitlab-ci.yml or .github/workflows)