Initial commit
This commit is contained in:
Zhongwei Li
145
skills/checking-code-quality/SKILL.md
Normal file
145
skills/checking-code-quality/SKILL.md
Normal 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
416
skills/checking-config-compliance/SKILL.md
Normal 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.
|
||||
@@ -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
713
skills/creating-plugins/SKILL.md
Normal 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
11
skills/creating-plugins/templates/marketplace.json.template
Normal 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
9
skills/creating-plugins/templates/plugin.json.template
Normal 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
163
skills/creating-pull-requests/SKILL.md
Normal 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
196
skills/helping-with-commits/SKILL.md
Normal 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
116
skills/running-quality-gate/SKILL.md
Normal 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)
|
||||
Reference in New Issue
Block a user