Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:26:47 +08:00
commit ba28d2ddd8
53 changed files with 7766 additions and 0 deletions

619
skills/README.md Normal file
View File

@@ -0,0 +1,619 @@
# Claude Code Skills - leapmultix
Ce répertoire contient les Skills Claude Code pour le projet leapmultix. Les Skills sont des capacités modulaires qui étendent les fonctionnalités de Claude en fournissant des instructions standardisées pour des workflows répétitifs.
## Skills disponibles
### 🔴 Haute priorité (implémentées)
#### 1. I18n Translation Sync
**Emplacement :** `i18n-sync/`
**Description :** Vérifie la synchronisation des fichiers de traduction (fr.json, en.json, es.json)
**Utilisation :** Claude active automatiquement cette skill quand vous travaillez sur les traductions
**Commandes manuelles :**
```bash
npm run i18n:compare
npm run i18n:verify
npm run i18n:unused
```
#### 2. Code Quality Gate
**Emplacement :** `checking-code-quality/`
**Description :** Exécute les vérifications de qualité (format:check, ESLint, Jest) avant commits
**Utilisation :** Claude active cette skill avant les commits et lors des revues de code
**Commandes manuelles :**
```bash
npm run format:check
npm run format
npm run lint
npm run lint:fix
npm test
npm run verify
```
#### 3. New Game Mode Creator
**Emplacement :** `game-mode/`
**Description :** Guide la création de nouveaux modes de jeu suivant l'architecture GameMode.js
**Utilisation :** Claude active cette skill lors de la création de nouveaux modes de jeu
**Fichiers de référence :**
- `js/core/GameMode.js` - Classe abstraite
- `js/modes/QuizMode.js` - Exemple simple
- `js/modes/ChallengeMode.js` - Exemple complexe
#### 4. TDD with Jest
**Emplacement :** `practicing-tdd-with-jest/`
**Description :** Implémente les fonctionnalités en suivant le cycle RED/GREEN/REFACTOR avec Jest
**Utilisation :** Claude active cette skill lors de l'ajout de features, corrections de bugs, ou refactoring
**Commandes manuelles :**
```bash
npm test # Tous les tests
npm run test:watch # Tests en mode watch
npm run test:coverage # Tests avec couverture
npm run test:verbose # Output détaillé
```
**Concepts couverts :**
- Cycle TDD : RED → GREEN → REFACTOR
- Assertions Jest (toBe, toEqual, toThrow, etc.)
- Mocking et spies
- Tests asynchrones
- Patterns pour Game Modes et Event Bus
#### 5. Accessibility Validator
**Emplacement :** `validating-accessibility/`
**Description :** Valide l'accessibilité web selon les standards WCAG 2.1 niveau AA
**Utilisation :** Claude active cette skill lors de modifications UI ou audits d'accessibilité
**Commandes manuelles :**
```bash
npm run audit:accessibility # Audit a11y complet
npm run audit:mobile # Audit mobile responsive
```
**Standards couverts :**
- Structure sémantique HTML
- Navigation clavier (Tab, Enter, Escape)
- Attributs ARIA (labels, roles, états)
- Contraste des couleurs (4.5:1 min)
- Alternatives textuelles (alt, aria-label)
- Focus visible et gestion du focus
- Tests avec lecteurs d'écran
#### 6. PWA Service Worker Manager
**Emplacement :** `pwa-service-worker/`
**Description :** Gère les mises à jour du Service Worker avec versioning du cache et tests offline
**Utilisation :** Claude active cette skill lors de modifications du SW ou ajout de ressources
**Commandes manuelles :**
```bash
npm run test:pwa-offline # Tester fonctionnalité offline
npm run sw:disable # Désactiver SW temporairement
npm run sw:fix # Réparer SW en cas de problèmes
```
**Concepts couverts :**
- Versioning de cache (SemVer)
- Stratégies de cache (Cache First, Network First)
- Événements SW (install, activate, fetch)
- Debugging avec Chrome DevTools
- Tests offline et mise à jour forcée
### 🟢 Phase 3 - Skills avancées (implémentées)
#### 7. JSDoc Generator
**Emplacement :** `jsdoc-generator/`
**Description :** Génère automatiquement la documentation JSDoc pour modules ES6
**Utilisation :** Claude active cette skill lors de documentation de fonctions/classes
**Commandes manuelles :**
```bash
npm run analyze:jsdoc # Analyser couverture JSDoc
npm run improve:jsdoc # Suggestions amélioration
```
**Concepts couverts :**
- Format JSDoc standard (@param, @returns, @throws, @example)
- Types TypeScript-like dans JSDoc
- Documentation de classes et modules
- @typedef pour types personnalisés
- Génération HTML avec JSDoc CLI
#### 8. Performance Profiler
**Emplacement :** `performance-profiler/`
**Description :** Analyse et optimise les performances (temps de chargement, FPS, mémoire)
**Utilisation :** Claude active cette skill lors de ralentissements ou optimisation
**Outils couverts :**
- Chrome DevTools Performance
- Lighthouse audits
- Performance API (performance.mark/measure)
- FPS monitoring
- Memory leak detection
**Objectifs :**
- FPS ≥ 60 dans jeux arcade
- First Contentful Paint < 1.5s
- Time to Interactive < 3s
- Memory usage stable
#### 9. Bundle Size Optimizer
**Emplacement :** `bundle-size-optimizer/`
**Description :** Analyse et réduit la taille des bundles JavaScript
**Utilisation :** Claude active cette skill lors d'ajout de dépendances ou bundle > 200 KB
**Commandes manuelles :**
```bash
npm run analyze:dependencies # Analyser dépendances
npm run verify:dead-code # Détecter code mort
```
**Stratégies :**
- Tree shaking et code splitting
- Lazy loading (déjà implémenté dans lazy-loader.js)
- Minification avec Terser
- Bundle analysis avec visualizer
#### 10. Asset Optimizer
**Emplacement :** `optimizing-assets/`
**Description :** Optimise images, sprites, sons et médias pour réduire bande passante
**Utilisation :** Claude active cette skill avant d'ajouter gros assets
**Commandes manuelles :**
```bash
npm run assets:generate # Générer versions responsive
npm run assets:analyze # Analyser utilisation
npm run assets:diff # Comparer avant/après
```
**Optimisations :**
- Compression images (PNG, JPG, WebP, AVIF)
- Sprite sheets et lazy loading
- Audio compression (MP3 96 kbps)
- Formats modernes avec fallback
### 🎮 Phase 4 - Skills spécialisées (implémentées)
#### 11. Arcade Game Creator
**Emplacement :** `creating-arcade-games/`
**Description :** Crée des jeux arcade canvas HTML5 suivant les patterns leapmultix
**Utilisation :** Claude active cette skill lors de création de nouveaux mini-jeux
**Architecture :**
- Engine (logique jeu)
- Renderer (rendu canvas)
- Controls (clavier + touch)
- Questions (intégration multiplication)
**Jeux de référence :**
- `multisnake.js` (38 KB) - Snake game
- `arcade-invasion.js` (31 KB) - Space Invaders
- `multimiam-*.js` - Multimiam décomposé
#### 12. Animation System Helper
**Emplacement :** `managing-animations/`
**Description :** Crée animations CSS et JavaScript (keyframes, transitions, sprite animations)
**Utilisation :** Claude active cette skill lors d'ajout d'animations visuelles
**Types d'animations :**
- CSS Keyframes (@keyframes fadeIn, pulse, shake, etc.)
- CSS Transitions (hover, active states)
- JavaScript requestAnimationFrame
- Sprite animations canvas
- Particle systems
**Performance :**
- GPU acceleration (transform, opacity)
- prefers-reduced-motion support
- 60 FPS maintenu
#### 13. Sound Effect Manager
**Emplacement :** `sound-effect-manager/`
**Description :** Gère effets sonores et audio pour feedback utilisateur
**Utilisation :** Claude active cette skill lors d'ajout de nouveaux sons
**Module existant :**
- `js/core/audio.js` - AudioManager complet
- playSound(), setVolume(), toggleMute()
**Patterns :**
- Sound pools (sons répétitifs)
- Fade in/out
- Musique de fond avec loop
- Web Audio API avancé
- Mobile autoplay handling
#### 14. Sprite Management
**Emplacement :** `sprite-management/`
**Description :** Gère sprites, sprite sheets, animations et collisions
**Utilisation :** Claude active cette skill lors de création de jeux ou ajout de personnages
**Features :**
- Sprite simple et sprite sheets
- Animations (idle, walk, jump, attack)
- Collisions (AABB, circle, spatial grid)
- Sprites directionnels (4 directions)
- Object pooling et culling
**Optimisations :**
- Batch rendering
- Spatial hashing pour collisions
- Culling (dessiner seulement visible)
## Comment utiliser les Skills
### Activation automatique
Les Skills s'activent automatiquement quand Claude détecte que le contexte correspond à leur description. Vous n'avez rien à faire de spécial.
**Exemples :**
```
Vous : "Je veux ajouter une nouvelle traduction pour le mode arcade"
→ Claude active automatiquement la skill "I18n Translation Sync"
Vous : "Je suis prêt à committer mes changements"
→ Claude active automatiquement la skill "Code Quality Gate"
Vous : "Je veux créer un nouveau mode de jeu pour apprendre les divisions"
→ Claude active automatiquement la skill "New Game Mode Creator"
Vous : "Je veux implémenter une nouvelle fonction en TDD"
→ Claude active automatiquement la skill "TDD with Jest"
Vous : "Peux-tu vérifier l'accessibilité de cette page ?"
→ Claude active automatiquement la skill "Accessibility Validator"
Vous : "Je dois mettre à jour le Service Worker"
→ Claude active automatiquement la skill "PWA Service Worker Manager"
```
### Vérifier les Skills disponibles
Demandez à Claude :
```
Quelles skills sont disponibles pour ce projet ?
```
### Tester une Skill
Posez une question qui correspond à la description de la skill :
```
Peux-tu vérifier que mes traductions sont synchronisées ?
→ Active "I18n Translation Sync"
Est-ce que mon code est prêt à être committé ?
→ Active "Code Quality Gate"
Comment créer un nouveau mode de jeu ?
→ Active "New Game Mode Creator"
Écris les tests en TDD pour cette fonction
→ Active "TDD with Jest"
Vérifie l'accessibilité de ce composant
→ Active "Accessibility Validator"
Comment mettre à jour le cache du Service Worker ?
→ Active "PWA Service Worker Manager"
```
## Structure d'une Skill
```
skill-name/
├── SKILL.md # Fichier principal (obligatoire)
├── resources/ # Documentation additionnelle (optionnel)
│ ├── reference.md
│ ├── examples.md
│ └── patterns.md
└── templates/ # Templates de code (optionnel)
└── template.js
```
### Anatomie de SKILL.md
```yaml
---
name: "Nom de la Skill"
description: "Description claire de QUAND et COMMENT utiliser cette skill"
---
# Titre de la Skill
## Quand utiliser cette skill
- Cas d'usage 1
- Cas d'usage 2
## Instructions étape par étape
1. Étape 1
2. Étape 2
## Exemples
Code ou exemples concrets
## Bonnes pratiques
Recommandations
## Voir aussi
Liens vers documentation
```
## Créer une nouvelle Skill
### Étape 1 : Créer la structure
```bash
mkdir -p .claude/skills/ma-skill
touch .claude/skills/ma-skill/SKILL.md
```
### Étape 2 : Écrire SKILL.md
Utilisez le template ci-dessus et assurez-vous que :
- Le `description` explique QUAND utiliser la skill
- Les instructions sont claires et actionnables
- Des exemples concrets sont fournis
- Les bonnes pratiques sont documentées
### Étape 3 : Tester la Skill
Redémarrez Claude Code et testez avec une question correspondante :
```
Peux-tu m'aider avec [description de ta skill] ?
```
### Étape 4 : Itérer
Basé sur l'utilisation :
- Raffiner la description pour meilleure découverte
- Ajouter des exemples manquants
- Déplacer le contenu long dans resources/
- Ajouter templates si nécessaire
## Bonnes pratiques
### Description efficace
**❌ Trop vague :**
```yaml
description: 'Aide avec les données'
```
**✅ Spécifique :**
```yaml
description: 'Vérifie la synchronisation des fichiers i18n (fr, en, es) et détecte clés manquantes, valeurs vides, incohérences de types. Utiliser lors de modifications de traductions.'
```
### Garder SKILL.md concis
- Maximum 500 lignes recommandé
- Déplacer détails dans resources/
- Utiliser progressive disclosure
- Privilégier exemples aux explications longues
### Organisation des fichiers
```
resources/
├── reference.md # Documentation détaillée
├── patterns.md # Patterns de code
├── examples.md # Exemples concrets
└── troubleshooting.md # Solutions aux problèmes courants
templates/
├── class-template.js # Template de classe
├── test-template.js # Template de test
└── config-template.json # Template de config
```
### Noms de fichiers descriptifs
**✅ Bon :**
- `resources/jest-patterns.md`
- `resources/gamemode-lifecycle.md`
- `templates/GameModeTemplate.js`
**❌ Éviter :**
- `resources/doc1.md`
- `resources/info.md`
- `templates/template.js`
## Partage et versioning
### Git
Les Skills dans `.claude/skills/` sont versionnées avec le projet :
```bash
git add .claude/skills/
git commit -m "Add i18n-sync skill"
git push
```
Les membres de l'équipe obtiennent automatiquement les skills après `git pull`.
### Documentation des versions
Ajoutez une section historique dans SKILL.md :
```markdown
## Historique des versions
- v1.1.0 (2025-10-19) : Ajout vérification types array/string
- v1.0.0 (2025-10-15) : Version initiale
```
## Debugging
### Skill ne s'active pas
**Vérifier :**
1. Description assez spécifique ?
2. YAML frontmatter valide ?
3. Fichier dans bon emplacement ?
**Tester :**
```bash
# Vérifier existence
ls .claude/skills/*/SKILL.md
# Vérifier frontmatter
cat .claude/skills/ma-skill/SKILL.md | head -n 10
# Mode debug
claude --debug
```
### Conflicts entre Skills
Si plusieurs skills correspondent, rendez les descriptions plus distinctes :
**❌ Trop similaire :**
```yaml
# Skill 1
description: "Pour l'analyse de données"
# Skill 2
description: "Pour analyser les données"
```
**✅ Distinct :**
```yaml
# Skill 1
description: "Analyser données de ventes Excel/CRM pour rapports revenus"
# Skill 2
description: "Analyser fichiers logs et métriques système pour diagnostics"
```
## Ressources
### Documentation officielle
- [Claude Code Skills Guide](https://docs.claude.com/en/docs/claude-code/skills)
- [Agent Skills Overview](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview)
- [Best Practices](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/best-practices)
### Exemples communautaires
- [Anthropic Official Skills](https://github.com/anthropics/skills)
- [obra/superpowers](https://github.com/obra/superpowers) - Core skills library
- [obra/superpowers-skills](https://github.com/obra/superpowers-skills) - Community skills
### Projet leapmultix
- `CLAUDE.md` - Documentation principale du projet
- `package.json` - Scripts npm disponibles
- `eslint.config.js` - Configuration ESLint
- `.prettierrc` - Configuration Prettier
## Contribution
Pour proposer une nouvelle skill :
1. Créer la skill dans votre branche
2. Tester avec cas d'usage réels
3. Documenter exemples et bonnes pratiques
4. Créer PR avec description du problème résolu
5. Équipe review et merge
## Support
Questions ou problèmes avec les Skills ?
1. Vérifier ce README
2. Consulter SKILL.md de la skill concernée
3. Tester avec `claude --debug`
4. Demander à Claude : "Explique-moi comment fonctionne la skill X"
## Roadmap
### Phase 1 ✅ - Skills de base (Complétée)
- [x] I18n Translation Sync
- [x] Code Quality Gate
- [x] New Game Mode Creator
### Phase 2 ✅ - Skills intermédiaires (Complétée)
- [x] TDD with Jest
- [x] Accessibility Validator
- [x] PWA Service Worker Manager
### Phase 3 ✅ - Skills avancées (Complétée)
- [x] JSDoc Generator - Documentation ES6 automatisée
- [x] Performance Profiler - Analyse et optimisation performance
- [x] Bundle Size Optimizer - Optimisation taille bundles
- [x] Asset Optimizer - Optimisation images et médias
### Phase 4 ✅ - Skills spécialisées (Complétée)
- [x] Arcade Game Creator - Template jeux arcade canvas
- [x] Animation System Helper - Animations CSS/JS
- [x] Sound Effect Manager - Gestion effets sonores
- [x] Sprite Management - Gestion sprites et animations
## 🎉 Toutes les skills ont été créées !
**Total : 14 skills opérationnelles** couvrant l'ensemble du cycle de développement de leapmultix, de la qualité du code aux jeux arcade en passant par l'optimisation et l'accessibilité.
## Licence
Ces Skills sont spécifiques au projet leapmultix et partagent la même licence que le projet principal.

View File

@@ -0,0 +1,214 @@
---
name: auditing-security
description: Audits application security (XSS, CSP, vulnerable dependencies, CORS). Use before releases, after adding dependencies, or modifying security-utils.js
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Security Audit
Audite la sécurité de l'application web selon standards OWASP et best practices.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Domaines de sécurité](#domaines-de-sécurité)
- [Checklist sécurité](#checklist-sécurité)
- [Outils d'audit](#outils-daudit)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant chaque release en production
- Après ajout/mise à jour dépendances npm
- Modifications de `security-utils.js`
- Warnings eslint-plugin-security
- Avant commit manipulant HTML dynamique
- Ajout de scripts externes (CDN, analytics)
## Domaines de sécurité
### 1. XSS (Cross-Site Scripting) Prevention
**Règle absolue : Utiliser security-utils.js**
Trouve security-utils.js pour voir fonctions disponibles :
- `appendSanitizedHTML()` - Insérer HTML dynamique
- `createSafeElement()` - Créer élément avec contenu sécurisé
- `setSafeMessage()` - Définir texte (pas HTML)
**Dangers :**
- `innerHTML` avec user input → XSS
- Fonctions d'exécution dynamique avec données externes
- Event handlers depuis user input
**Exceptions sécurisées :**
- `innerHTML = ''` (nettoyage)
- `getTranslation()` output (contenu interne)
### 2. Content Security Policy (CSP)
**Principe : Meta tag CSP dans index.html**
Examine index.html pour voir configuration CSP actuelle.
**Baseline restrictive :**
- `default-src 'self'`
- Pas de `'unsafe-eval'` dans script-src
- `'unsafe-inline'` limité au strict nécessaire
- `frame-ancestors 'none'` pour prévenir clickjacking
**Scripts externes :**
- Toujours `crossorigin="anonymous"`
- Integrity hashes pour bibliothèques statiques
- PAS d'integrity pour analytics (auto-update)
- Documenter exceptions avec commentaires
### 3. Dependency Vulnerabilities
**Commandes audit :**
```bash
npm audit # Scan vulnérabilités
npm audit --json # Rapport détaillé
npm audit fix # Fix auto (patch/minor)
npm audit fix --force # Fix breaking (attention!)
```
**Niveaux de sévérité :**
- **Critical/High** : Fix immédiatement avant release
- **Moderate** : Fix dans sprint suivant
- **Low** : Monitorer, fix si possible
**Vérifier :**
- Pas de dépendances deprecated
- Versions à jour (pas trop anciennes)
- Licences compatibles
### 4. HTTPS et Mixed Content
**Vérifier :**
- HTTPS obligatoire en production
- Pas de resources HTTP (mixed content)
- Redirection HTTP → HTTPS
- HSTS header
Examine configuration serveur ou CDN.
### 5. Secrets et Credentials
**Règles :**
- **JAMAIS** committer secrets (API keys, tokens, passwords)
- **JAMAIS** stocker passwords en LocalStorage
- Utiliser variables d'environnement
- .gitignore pour fichiers sensibles (.env, credentials.json)
**Vérifier :**
- Pas de secrets hardcodés dans code
- .env dans .gitignore
- Terraform state pas committé
### 6. LocalStorage Security
**Données sensibles :**
- **JAMAIS** tokens d'authentification
- **JAMAIS** passwords ou PII
- OK pour préférences utilisateur non sensibles
**Vérifier :**
- storage.js utilise localStorage correctement
- Pas de données sensibles stockées
- Données validées avant lecture
## Checklist sécurité
- [ ] Tous `innerHTML` utilisent `appendSanitizedHTML()` ou justifiés
- [ ] Pas de fonctions d'exécution dynamique avec données externes
- [ ] Meta tag CSP présent dans index.html
- [ ] `crossorigin="anonymous"` sur scripts externes
- [ ] `npm audit` sans Critical/High
- [ ] Pas de secrets hardcodés
- [ ] Pas de données sensibles en LocalStorage
- [ ] HTTPS en production
- [ ] Pas de mixed content
- [ ] Tests sécurité passent
## Outils d'audit
**ESLint Security :**
```bash
npm run lint # Inclut eslint-plugin-security
```
**Dependency Scan :**
```bash
npm audit
```
**Lighthouse Security Audit :**
- Lance Chrome DevTools → Lighthouse
- Vérifie section Security
- Score doit être 100
**OWASP ZAP (optionnel) :**
- Scan automatisé pour vulnérabilités web
- Tests de pénétration
## En cas de doute
**Source :** security-utils.js + CLAUDE.md
**Fichiers clés :**
1. `js/security-utils.js` - Fonctions sécurité du projet
2. `eslint.config.js` - Règles security ESLint
3. `index.html` - Configuration CSP
4. `CLAUDE.md` - Guidelines sécurité
**Règles absolues :**
1. TOUJOURS utiliser security-utils.js pour manipulation DOM
2. TOUJOURS audit avant release (`npm audit`)
3. JAMAIS `innerHTML` avec user input direct
4. JAMAIS stocker données sensibles en LocalStorage
5. JAMAIS scripts externes sans `crossorigin="anonymous"`
**Workflow minimal avant commit :**
```bash
npm run lint # ESLint security rules
npm audit # Dependency check
npm test # Security tests
```
**Workflow complet avant release :**
```bash
npm run verify # Full quality gate
npm audit --audit-level=moderate # Dependency audit
# Lighthouse security audit
# Review index.html CSP config
```
**Red flags (arrêter immédiatement) :**
- Fonctions d'exécution dynamique avec données externes
- `innerHTML = userInput`
- Tokens/passwords en LocalStorage
- npm audit Critical/High
- Scripts CDN sans crossorigin

View File

@@ -0,0 +1,100 @@
---
name: optimizing-bundle-size
description: Analyzes and reduces JavaScript bundle size for fast loading. Use when adding dependencies, before releases, or if bundle exceeds 200KB
allowed-tools: Read, Grep, Glob, Bash
---
# Optimiseur de Taille de Bundle
Optimise taille des bundles JavaScript pour chargement rapide et performance mobile.
## Quand utiliser
- Ajout de nouvelles dépendances
- Bundle > 200 KB (gzipped)
- Avant chaque release
- Optimisation mobile (3G/4G)
- Audit de performance
## Cibles de taille
- Bundle initial : < 100 KB (gzipped)
- Bundle total : < 500 KB
- Modules individuels : < 50 KB
## Stratégies essentielles
### Tree Shaking
- Imports nommés (pas `import *`)
- Imports spécifiques de modules externes
- Named exports (pas d'export default d'objets)
### Code Splitting
- Import dynamique avec `import()`
- Lazy loading de composants lourds
- Vérifier lazy loading des modes de jeu
### Minification & Compression
- Minifier actif en production
- Gzip/Brotli sur serveur (-70% taille)
- Source maps pour debug
### Éliminer duplications
- Détecter code similaire entre modules
- Extraire logique partagée
- Cherche jeux arcade avec patterns similaires
## Outils d'analyse
**Scripts npm :**
- `npm run analyze:dependencies` - Dépendances non utilisées
- `npm run dead-code` - Exports/fonctions jamais appelés
- `npm run analyze:globals` - Variables globales
- `npm run analyze:assets` - Assets volumineux
**Mesurer impact :**
- Taille gzippée avant/après
- Lighthouse CI (Performance > 90)
- Tests mobile 3G/4G
## Workflow
1. **Analyser :** Lancer scripts npm d'analyse
2. **Identifier :** Code mort, modules lourds, imports sous-optimaux
3. **Optimiser :** Une stratégie à la fois (lazy loading > tree shaking > minification)
4. **Mesurer :** Taille gzippée, temps chargement, Lighthouse
5. **Valider :** Tests passent, mobile performant
## Checklist
- [ ] Scripts d'analyse exécutés
- [ ] Imports optimisés (spécifiques, pas wildcard)
- [ ] Code mort retiré
- [ ] Lazy loading vérifié
- [ ] Minification/Gzip activés
- [ ] Lighthouse > 90 (Performance)
- [ ] Bundle < 100 KB (gzipped)
## En cas de doute
**Règles absolues :**
1. Toujours mesurer avant/après
2. Une optimisation à la fois
3. Priorité : lazy loading > tree shaking > minification
4. Mobile 3G/4G = référence
5. Tests passent après chaque changement
**Workflow minimal :**
```bash
npm run analyze:dependencies # Identifier code mort
npm run dead-code # Vérifier exports non utilisés
npm run analyze:assets # Vérifier assets volumineux
```

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é

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.

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

View File

@@ -0,0 +1,241 @@
---
name: creating-arcade-games
description: Creates HTML5 canvas arcade games following leapmultix patterns (Multimiam, Multisnake, Invasion). Use when creating new arcade mini-games
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Arcade Game Creator
Guide la création de nouveaux jeux arcade canvas pour le mode Arcade.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Jeux existants (références)](#jeux-existants-références)
- [Patterns architecturaux](#patterns-architecturaux)
- [Composants essentiels](#composants-essentiels)
- [Workflow de création](#workflow-de-création)
- [Patterns de gameplay](#patterns-de-gameplay)
- [Performance (viser 60 FPS)](#performance-viser-60-fps)
- [Checklist](#checklist)
- [Debugging](#debugging)
- [Outils disponibles](#outils-disponibles)
- [En cas de doute](#en-cas-de-doute)
- [Références](#références)
## Quand utiliser
- Création d'un nouveau jeu arcade
- Extension du mode Arcade
- Adaptation de jeux existants
- Prototypage de mini-jeux
## Jeux existants (références)
### Architecture simple
**Arcade Multi Memory** (31 KB) :
- Jeu de memory matching
- Structure monolithique simple
- Bon point de départ
**Arcade Invasion** (31 KB) :
- Space Invaders style
- Gestion d'entités multiples
- Pattern de vagues d'ennemis
### Architecture décomposée
**Multimiam** (architecture modulaire) :
- Point d'entrée + modules séparés
- Engine (logique), Renderer (rendu), Controls (inputs), Questions (multiplication)
- Meilleure maintenabilité
**Multisnake** (38 KB) :
- Structure plus monolithique
- Gestion de grille
## Patterns architecturaux
### Pattern monolithique
Tout dans un fichier. Simple pour jeux petits.
**Quand utiliser** : Jeux simples, prototypes
### Pattern décomposé
Séparation en modules (Engine, Renderer, Controls, Questions).
**Quand utiliser** : Jeux complexes, maintenance long terme
Examine Multimiam pour voir ce pattern en action.
## Composants essentiels
### Game Loop
Boucle continue : update → render → next frame (requestAnimationFrame)
### Système de rendu Canvas
Clear canvas → Draw entities → Draw UI
### Gestion des inputs
Support clavier ET touch pour mobile
### Intégration questions multiplication
Questions intégrées au gameplay, pas séparées
Cherche ces patterns dans les jeux existants.
## Workflow de création
### Étape 1 : Choisir un jeu de référence
Identifie le jeu existant qui ressemble le plus au tien :
- Jeu de puzzle/memory → arcade-multimemory.js
- Jeu de tir/action → arcade-invasion.js
- Jeu de grille → multisnake.js
### Étape 2 : Décider de l'architecture
**Jeu simple** : Fichier unique `arcade-new-game.js`
**Jeu complexe** : Fichiers multiples
- `new-game.js` (point d'entrée)
- `new-game-engine.js` (logique)
- `new-game-renderer.js` (rendu)
- `new-game-controls.js` (inputs)
### Étape 3 : Comprendre le pattern de référence
Examine le jeu choisi :
- Comment l'initialisation fonctionne ?
- Comment le game loop est structuré ?
- Comment le rendu est organisé ?
- Comment les questions sont intégrées ?
Adapte (ne copie pas aveuglément).
### Étape 4 : Intégrer dans mode Arcade
Trouve où les jeux arcade sont enregistrés.
Ajoute ton jeu suivant le même pattern.
### Étape 5 : Ajouter UI et traductions
- Ajoute bouton dans HTML (cherche structure existante)
- Crée traductions (fr → en → es)
- Vérifie synchronisation i18n
## Patterns de gameplay
### Collision detection
Cherche comment les jeux existants détectent les collisions (AABB pattern courant).
### Spawning d'entités
Trouve comment les ennemis/objets sont créés dans les jeux.
### Scoring et progression
Examine les systèmes de score et de niveaux dans les jeux existants.
## Performance (viser 60 FPS)
**Techniques essentielles** :
- `requestAnimationFrame` (pas `setInterval`)
- Object pooling pour entités
- Éviter allocations mémoire dans game loop
- Optimiser opérations canvas
Cherche exemples de ces optimisations dans le code existant.
## Checklist
### Découverte
- [ ] Examiner jeu similaire existant
- [ ] Comprendre architecture (monolithique ou décomposée)
- [ ] Identifier patterns de game loop et rendu
### Implémentation
- [ ] Fichiers créés avec convention de nommage
- [ ] Game loop avec requestAnimationFrame
- [ ] Rendu canvas fonctionnel
- [ ] Controls clavier ET touch
- [ ] Questions multiplication intégrées
- [ ] Sons joués (correct/wrong)
### Intégration
- [ ] Intégré dans mode Arcade
- [ ] Bouton ajouté dans HTML
- [ ] Traductions ajoutées
- [ ] `npm run i18n:compare` passe
### Qualité
- [ ] Performance 60 FPS (tester sur mobile)
- [ ] Cleanup des listeners (pas de leaks)
- [ ] Tests si logique complexe
- [ ] Code formatté et lint passe
## Debugging
### Problèmes de performance
Utilise Chrome DevTools → Performance tab
Enregistre pendant le jeu et cherche frame drops
### Problèmes de rendu
Vérifie ordre de rendu (background → entités → UI)
### Problèmes d'inputs
Vérifie event listeners attachés et retirés proprement
## Outils disponibles
Examine le code pour trouver :
- Fonctions audio (playSound)
- Event bus (communication avec UI)
- Utils généraux (utils-es6.js)
- Question generator (questionGenerator.js)
- Fonctions communes arcade (arcade-common.js, arcade-utils.js)
## En cas de doute
**Code existant = source de vérité**
1. Choisis jeu similaire comme référence
2. Comprends son architecture avant de coder
3. Adapte les patterns
4. Teste fréquemment (surtout performance)
5. Mobile-first : teste sur touch dès le début
## Références
Cherche dans le code :
- `js/arcade-multimemory.js` - Jeu simple
- `js/arcade-invasion.js` - Space invaders
- `js/multimiam*.js` - Architecture décomposée
- `js/multisnake.js` - Snake
- `js/arcade-common.js` - Fonctions communes
- `js/questionGenerator.js` - Génération questions

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

View File

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

View File

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

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 "..."
```

View File

@@ -0,0 +1,159 @@
---
name: managing-dependencies
description: Manages npm dependencies (audit, updates, breaking changes, lockfile). Use before releases, after adding packages, or monthly for maintenance
allowed-tools: Read, Grep, Glob, Bash
---
# Gestion des Dépendances
Gère dépendances npm de manière sécurisée (audit, mises à jour, lockfile).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Scripts npm](#scripts-npm)
- [Workflows essentiels](#workflows-essentiels)
- [Gestion vulnérabilités](#gestion-vulnérabilités)
- [Migrations majeures](#migrations-majeures)
- [Bonnes pratiques](#bonnes-pratiques)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant chaque release production
- Après ajout nouvelles dépendances
- Mensuellement maintenance proactive
- Quand vulnérabilités signalées
- Migrations versions majeures
## Scripts npm
- `npm audit` - Vue d'ensemble sécurité
- `npm audit --json` - Rapport détaillé
- `npm audit fix` - Fix auto (patch/minor)
- `npm outdated` - Packages à mettre à jour
- `npm update` - Update patches/minors
- `npm ls` / `npm ls --depth=0` - Arbre dépendances
## Workflows essentiels
**Audit sécurité :**
- CRITICAL/HIGH → Corriger immédiatement
- MODERATE → Corriger avant release
- LOW → Corriger quand possible
**Types mises à jour (SemVer) :**
- Patch (1.0.x) → Bugs, sécurisé
- Minor (1.x.0) → Features, rétrocompatible
- Major (x.0.0) → Breaking, nécessite tests
**Stratégie :**
- Patches → Auto si tests passent
- Minors → Manuel vérification
- Majors → Manuel migration plan
**Lockfile :**
- Garantit versions exactes
- Commit toujours avec package.json
- Désynchronisé → `npm install`
- Conflit merge → Résoudre + `npm install`
## Gestion vulnérabilités
**Critiques/Hautes :** Fix immédiat, tester, déployer rapidement
**Sans fix :** Package alternatif, fork + patch, monitorer, désactiver si possible
**Packages deprecated :** Chercher alternatives maintenues, planifier migration
## Migrations majeures
**Préparation :**
1. Lire CHANGELOG (breaking changes)
2. Estimer impact code
3. Créer branche dédiée
**Exécution :**
1. Update package.json
2. Adapter code aux breaking changes
3. Corriger erreurs TS/ESLint
4. Tests exhaustifs
**Validation :**
- Tests passent
- Lighthouse score OK
- Performance stable
- Pas régressions visuelles
## Bonnes pratiques
**Do's :**
- Commit lockfile toujours
- Audit hebdomadaire minimum
- Tests après update
- Un update à la fois
- Lire CHANGELOG majors
- Respecter SemVer
**Don'ts :**
- Pas `npm install --force` (sauf urgence)
- Pas updates aveugles
- Pas lockfile .gitignore
- Pas updates avant release
- Pas dépendances non maintenues
## Checklist
- [ ] `npm audit` sans CRITICAL/HIGH
- [ ] `npm outdated` vérifié
- [ ] Lockfile synchronisé
- [ ] Tests passent après update
- [ ] Build OK
- [ ] Performance stable
- [ ] Pas deprecated packages
- [ ] CHANGELOG lu (majors)
- [ ] Lockfile committé
## En cas de doute
**Règles absolues :**
1. `npm audit` AVANT release obligatoire
2. Tester APRÈS mise à jour
3. Jamais ignorer lockfile
4. CHANGELOG pour majors
5. CRITICAL/HIGH fix immédiat
**Workflow mensuel :**
```bash
npm outdated
npm audit
npm update
npm test
```
**Workflow avant release :**
```bash
npm audit --audit-level=moderate
npm outdated
npm test
npm run build
```
**Références :**
- package.json - Versions actuelles
- package-lock.json - Lockfile
- npm docs - Documentation

220
skills/game-mode/SKILL.md Normal file
View File

@@ -0,0 +1,220 @@
---
name: creating-game-modes
description: Creates new game modes by extending the abstract GameMode.js class with lifecycle management, event bus, and lazy loading
allowed-tools: Read, Write, Grep, Glob, Bash
---
# New Game Mode Creator
Guide la création de nouveaux modes de jeu suivant l'architecture établie du projet.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Architecture des Game Modes](#architecture-des-game-modes)
- [Workflow de création](#workflow-de-création)
- [Patterns et conventions](#patterns-et-conventions)
- [Checklist de création](#checklist-de-création)
- [Debugging](#debugging)
- [En cas de doute](#en-cas-de-doute)
- [Références](#références)
## Quand utiliser
- Création d'un nouveau mode de jeu
- Extension de la fonctionnalité arcade
- Ajout de variantes de modes existants
- Migration de code legacy vers pattern GameMode
## Architecture des Game Modes
### Principes fondamentaux
**Héritage** : Tous les modes héritent de `GameMode` (classe abstraite)
**Communication** :
- Utilise `eventBus` pour découplage (jamais de couplage direct)
- Pattern publish/subscribe pour événements
**Chargement** : Lazy loading via le système existant
**Cycle de vie** : `init()``start()``update()``cleanup()`
- Toujours nettoyer les listeners dans `cleanup()`
### Méthodes abstraites requises
À implémenter dans tout mode :
- `init()` - Initialisation
- `cleanup()` - Nettoyage et libération ressources
- `handleQuestion()` - Traitement d'une question
- `handleCorrectAnswer()` - Gestion réponse correcte
- `handleWrongAnswer()` - Gestion réponse incorrecte
- `updateUI()` - Mise à jour interface
- `showResults()` - Affichage résultats
## Workflow de création
### Étape 1 : Explorer les exemples existants
Examine les modes dans `js/modes/` :
- **QuizMode.js** : Mode simple, bon point de départ
- **ChallengeMode.js** : Mode avec timer, patterns avancés
- **ArcadeMode.js** : Collection de mini-jeux
Trouve celui qui ressemble le plus à ce que tu veux créer.
### Étape 2 : Localiser la classe abstraite
Trouve et examine `GameMode.js` pour comprendre :
- Les méthodes abstraites obligatoires
- Les méthodes utilitaires disponibles
- Le contrat d'interface
### Étape 3 : Comprendre l'intégration
Cherche dans le code existant :
- Comment les modes sont enregistrés (gestionnaire de modes)
- Comment le lazy loading fonctionne
- Comment les modes communiquent via eventBus
### Étape 4 : Créer ton mode
**Convention de nommage** : `js/modes/YourMode.js` (PascalCase)
**Structure minimale** :
- Hérite de GameMode
- Implémente toutes les méthodes abstraites
- Utilise eventBus pour communication
- Nettoie proprement dans cleanup()
Adapte un exemple existant à ton besoin.
### Étape 5 : Intégrer
- Enregistre dans le gestionnaire de modes
- Ajoute au lazy loader
- Crée les traductions (fr, en, es)
- Vérifie synchronisation i18n
### Étape 6 : Tester
```bash
npm test YourMode.test.js
npm run format:check
npm run lint
npm run i18n:compare
```
## Patterns et conventions
### Communication via Event Bus
**Principe** : Ne jamais coupler directement les composants
**Pattern typique** :
- Émettre : `eventBus.emit('mode:event', data)`
- Écouter : `eventBus.on('user:action', this.handler)`
- Nettoyer : `eventBus.off('user:action', this.handler)`
Cherche des exemples dans les modes existants.
### Gestion de l'état
Trouve comment les modes existants gèrent leur état interne.
Pattern commun : objet `this.state` avec propriétés du jeu.
### Utilisation des utilitaires
Examine `utils-es6.js` pour voir les fonctions disponibles :
- Génération de nombres aléatoires
- Mélange d'arrays
- Formatage du temps
- Etc.
## Checklist de création
### Découverte
- [ ] Examiner au moins 1 mode existant similaire
- [ ] Comprendre GameMode (classe abstraite)
- [ ] Identifier où les modes sont enregistrés
- [ ] Trouver le pattern de lazy loading
### Implémentation
- [ ] Fichier créé dans `js/modes/`
- [ ] Hérite de GameMode
- [ ] Toutes méthodes abstraites implémentées
- [ ] Event bus utilisé (pas de couplage direct)
- [ ] Cleanup proper (listeners retirés)
### Intégration
- [ ] Enregistré dans gestionnaire
- [ ] Ajouté au lazy loader
- [ ] Traductions ajoutées (fr → en → es)
- [ ] `npm run i18n:compare` passe
### Qualité
- [ ] Tests créés et passent
- [ ] Code formatté (`npm run format`)
- [ ] Lint passe (`npm run lint`)
- [ ] Documentation JSDoc
- [ ] Testé manuellement
## Debugging
### Vérifier initialisation
Cherche les patterns de logging dans les modes existants.
### Vérifier event bus
Liste tous les événements émis par les modes existants pour comprendre les conventions.
### Problèmes courants
**Mode ne se charge pas** :
- Vérifie enregistrement dans gestionnaire
- Vérifie configuration lazy loader
**Event bus ne fonctionne pas** :
- Vérifie que cleanup retire les listeners
- Cherche la bonne signature des événements
**Traductions manquantes** :
```bash
npm run i18n:compare
```
## En cas de doute
**Source de vérité = code existant**
1. Explore les modes similaires
2. Le code réel est plus fiable que toute documentation
3. Adapte les patterns, ne copie pas aveuglément
4. Teste fréquemment
## Références
Cherche dans le code :
- `js/core/GameMode.js` - Classe abstraite
- `js/modes/` - Tous les modes existants
- `js/core/GameModeManager.js` - Gestionnaire
- `js/lazy-loader.js` - Configuration lazy loading
- `js/core/eventBus.js` - Event bus

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"
```

169
skills/i18n-sync/SKILL.md Normal file
View File

@@ -0,0 +1,169 @@
---
name: synchronizing-i18n-translations
description: Verifies translation files synchronization (fr.json, en.json, es.json) and detects missing keys, empty values, and type inconsistencies
allowed-tools: Read, Grep, Glob, Bash
---
# I18n Translation Synchronization
Maintient la synchronisation des fichiers de traduction pour toutes les langues supportées.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Langues supportées](#langues-supportées)
- [Scripts disponibles](#scripts-disponibles)
- [Workflow principal](#workflow-principal)
- [Détection automatique](#détection-automatique)
- [Corriger les erreurs](#corriger-les-erreurs)
- [Structure des fichiers](#structure-des-fichiers)
- [Checklist i18n](#checklist-i18n)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout de nouveaux textes UI
- Modification de traductions existantes
- Avant de committer changements i18n
- Quand `npm run i18n:compare` signale erreurs
## Langues supportées
- **fr.json** (référence) - Toujours modifier en premier
- **en.json** (anglais)
- **es.json** (espagnol)
## Scripts disponibles
```bash
npm run i18n:compare # Compare tous les fichiers (PRINCIPAL)
npm run i18n:verify # Vérifie cohérence
npm run i18n:unused # Détecte clés inutilisées
```
## Workflow principal
### 1. Vérifier l'état actuel
```bash
npm run i18n:compare
```
Si erreurs, lire le rapport détaillé.
### 2. Modifier les traductions
**Règle d'or :** Toujours commencer par `fr.json`
1. Modifie `fr.json` d'abord
2. Copie la STRUCTURE (pas les valeurs) dans en.json et es.json
3. Traduis les valeurs
### 3. Vérifier synchronisation
```bash
npm run i18n:compare
```
Doit afficher : "Tous les fichiers de traduction sont parfaitement synchronisés !"
### 4. Tester dans l'UI
Lance l'application et teste le sélecteur de langue.
## Détection automatique
Le script `npm run i18n:compare` détecte :
**Clés manquantes :**
- Clés présentes dans fr.json mais absentes dans en.json/es.json
**Clés supplémentaires :**
- Clés présentes dans en.json/es.json mais absentes dans fr.json
**Valeurs vides :**
- `""`, `null`, `undefined`, `[]`
**Incohérences de types :**
- String vs Array (ex: fr.json = "text", en.json = ["array"])
**Format du rapport :**
- Console détaillée
- JSON exporté dans `docs/translations-comparison-report.json`
## Corriger les erreurs
### Clés manquantes
Ajoute les clés manquantes dans en.json/es.json avec traductions appropriées.
### Clés supplémentaires
Supprime les clés supplémentaires OU ajoute-les dans fr.json si nécessaires.
### Valeurs vides
Remplace les valeurs vides par traductions appropriées.
### Types incohérents
Uniformise le type (soit String partout, soit Array partout).
## Structure des fichiers
**Format JSON :**
```json
{
"key": "value",
"nested": {
"key": "value"
},
"array": ["item1", "item2"]
}
```
**Dot notation :**
- `key` → "key"
- `nested.key` → "nested.key"
- `array` → "array"
Le script aplatit la structure en dot notation pour comparaison.
## Checklist i18n
- [ ] fr.json modifié en premier
- [ ] Structure copiée dans en.json et es.json
- [ ] Valeurs traduites correctement
- [ ] `npm run i18n:compare` passe (100% synchronisé)
- [ ] Testé dans UI avec sélecteur de langue
- [ ] Pas de valeurs vides
- [ ] Types cohérents (String ou Array)
## En cas de doute
**Source :** fr.json + npm scripts
**Règles absolues :**
1. Toujours vérifier avec `npm run i18n:compare`
2. fr.json est la référence (pas en.json, pas es.json)
3. Ne jamais committer avec erreurs i18n
4. Tester dans UI avant commit
5. Scripts npm détectent TOUS les problèmes
**Workflow minimal :**
```bash
# Modifier fr.json
npm run i18n:compare # Vérifier
# Copier structure dans en.json, es.json
# Traduire valeurs
npm run i18n:compare # DOIT être OK
```

View File

@@ -0,0 +1,117 @@
---
name: generating-jsdoc
description: Automatically generates JSDoc documentation for ES6 modules with @param, @returns, @throws and examples. Use when adding functions, refactoring, or improving documentation
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Générateur JSDoc
Génère documentation JSDoc pour modules ES6 (functions, classes, exports).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Scripts npm](#scripts-npm)
- [Format JSDoc essentiel](#format-jsdoc-essentiel)
- [Patterns projet](#patterns-projet)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout fonctions ou classes
- Refactoring code
- Amélioration documentation
- Avant release
- Onboarding développeurs
## Scripts npm
- `npm run analyze:jsdoc` - Couverture JSDoc
- `npm run improve:jsdoc` - Améliorer documentation
- JSDoc HTML generation (si configuré)
## Format JSDoc essentiel
**Fonction :**
```javascript
/**
* Description brève (impératif : "Calcule", pas "Cette fonction")
*
* @param {Type} paramName - Description
* @param {Type} paramName2 - Description
* @returns {Type} Description retour
* @throws {ErrorType} Conditions erreur
* @example
* functionName(value1, value2); // → result
*/
```
**Classe :**
```javascript
/**
* Description classe
* @class
* @extends ParentClass
*/
export class ClassName {}
```
**Types :** `string`, `number`, `boolean`, `Array<Type>`, `{key: Type}`, `Promise<Type>`, `Type1|Type2`
## Patterns projet
**Priorités :**
- Haute : API publiques, fonctions complexes, classes
- Moyenne : Méthodes, callbacks, utilitaires
- Basse : Fonctions privées simples, getters évidents
**Tags spéciaux :**
- `@typedef` - Définir types complexes
- `@fires` - Événements émis
- `@deprecated` - Code obsolète
- `@see {@link Name}` - Références croisées
Examine code existant (modes, utils, core) pour patterns.
## Workflow
1. **Analyser :** `npm run analyze:jsdoc` → Identifier gaps
2. **Documenter :** Description + @param + @returns + @example
3. **Enrichir :** Cas limites, erreurs (@throws)
4. **Vérifier :** Code cohérent, types précis, exemples du domaine
## Checklist
- [ ] Description brève et impérative
- [ ] @param pour chaque paramètre avec type précis
- [ ] @returns avec type et description
- [ ] @throws si erreurs possibles
- [ ] @example (au moins 1 cas réaliste)
- [ ] @typedef pour types complexes
- [ ] Types précis (pas {Object} générique)
- [ ] Exemples avec valeurs du domaine
- [ ] Cas limites documentés (null, undefined)
- [ ] Cohérent avec reste projet
## En cas de doute
**Règles absolues :**
1. Description impérative (imperative mood)
2. Types explicites (jamais {\*} sauf dernier recours)
3. Exemples du domaine (réalistes)
4. @example obligatoire pour API publiques
5. Maintenir à jour avec refactoring
**Références :**
- Code existant patterns (modes, utils)
- `npm run analyze:jsdoc` - Vérifier couverture
- JSDoc.app - Syntaxe spécifique
- Examiner fichiers bien documentés du projet

View File

@@ -0,0 +1,118 @@
---
name: managing-animations
description: Creates and manages CSS and JavaScript animations (keyframes, transitions, sprite animations, canvas animations). Use when adding visual animations or user feedback
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Système d'Animation
Crée animations fluides (CSS, JS, sprites, particules) pour feedback utilisateur et jeux.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Types d'animations](#types-danimations)
- [Patterns essentiels](#patterns-essentiels)
- [Optimisations](#optimisations)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Feedback visuel (boutons, transitions)
- Animations sprites (jeux arcade)
- Transitions slides
- Effets visuels (particules, explosions)
- Micro-interactions UI
- Animations canvas jeux
## Types d'animations
**CSS Transitions :**
- Hover, focus, state changes
- Propriétés : transform, opacity (GPU), color, box-shadow
- Easing : ease-out (UI), ease-in-out (transitions), linear (rotations)
**CSS Keyframes :**
- Pulse, shake, bounce, rotate, fade
- Animations répétables sans événement
- Trouve keyframes existantes dans CSS
**JavaScript (requestAnimationFrame) :**
- Animations complexes programmées
- `performance.now()` → progress (0-1) → easing → interpolate
- Batch multiple animations dans un RAF
**Sprite Animations (Canvas) :**
- Frame-based (FPS adaptatif)
- Sprite sheets, frame index qui boucle
- Directional sprites, callbacks (onLoop, onComplete)
**Particle Systems :**
- Effets visuels (explosions, étincelles)
- Particle class (position, velocity, life, color)
- Max 100 simultanées, object pooling, cleanup
Examine animationen existantes dans le code.
## Patterns essentiels
- **Feedback :** Correct (vert, pulse), Wrong (rouge, shake), Coins (trajectoires)
- **Transitions slides :** TranslateX, fade, cleanup, historique
- **Accessibility :** Respecter `prefers-reduced-motion`, fallback simple
- **Easing :** Linear, Quad, Cubic, Elastic, Bounce (trouve dans utils)
## Optimisations
**GPU Acceleration :**
- Utiliser transform + opacity (pas left/top)
- will-change: transform, opacity (retirer après)
**Performance :**
- Batch RAF multiple animations
- Particules < 100 simultanées, cleanup chaque frame
- 60 FPS obligatoire (profile DevTools)
## Workflow
1. **Choisir type :** CSS transition (simple), CSS keyframes (feedback), RAF (complexe), Sprite (jeu), Particles (effets)
2. **Examiner existant :** Patterns, conventions, optimisations
3. **Implémenter :** Suivre mêmes patterns, cleanup, 60 FPS
4. **Tester :** Fluide, prefers-reduced-motion OK, mobile OK
## Checklist
- [ ] CSS pour animations simples
- [ ] RAF pour animations complexes
- [ ] transform + opacity (GPU)
- [ ] prefers-reduced-motion respecté
- [ ] Particules < 100, cleanup
- [ ] Easing appropriée
- [ ] 60 FPS maintenu
- [ ] Testé mobile
## En cas de doute
**Règles absolues :**
1. Examiner animations similaires dans code
2. Prioriser CSS (simplicité + perf)
3. JavaScript uniquement si nécessaire
4. Profile DevTools (60 FPS OBLIGATOIRE)
5. Toujours respecter prefers-reduced-motion
**Références :**
- CSS keyframes/transitions existantes
- Feedback animations (coins, scores)
- Slides transitions
- Jeux arcade (sprites, particules)
- Easing functions utils

View File

@@ -0,0 +1,121 @@
---
name: optimizing-assets
description: Optimizes images, sprites, sounds and media to reduce bandwidth and improve loading. Use before adding large assets or during mobile optimization
allowed-tools: Read, Grep, Glob, Bash
---
# Asset Optimizer
Optimise images, sprites, sons, vidéos pour chargement rapide et performance mobile.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Objectifs de taille](#objectifs-de-taille)
- [Principes essentiels](#principes-essentiels)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Avant ajouter images/sprites
- Assets > 100 KB
- Optimisation mobile (3G/4G)
- Audit Lighthouse Performance
- PWA bande passante
- Images non responsive
## Objectifs de taille
- Images PNG: < 50 KB, JPG: < 30 KB
- Audio: < 50 KB (96-128 kbps)
- Sprites: < 100 KB total
- Total first load: < 2 MB
- Lighthouse Performance: > 90
## Principes essentiels
**Images :**
- Compresse (TinyPNG, Squoosh): -30-50% PNG, -20-40% JPG
- WebP + fallback PNG/JPG (-25% vs JPG)
- Responsive (1x, 2x, 3x via srcset)
- Lazy loading (loading="lazy" ou Intersection Observer)
**Audio :**
- Bitrate: 96 kbps effets, 128 kbps musique
- Formats: MP3 + OGG/WebM (compatibilité)
- Preload sons critiques
**Sprites :**
- Combiner en sheets (moins requêtes HTTP)
- SVG icônes (scalable, modifiable CSS)
- Optimize avec SVGO
**Cache :**
- cache-updater.js (versioning auto)
- responsive-image-loader.js (chargement adapté densité)
## Workflow
1. **Analyser :** `npm run assets:analyze`
2. **Compresser :** Images TinyPNG/Squoosh, audio bitrate
3. **Intégrer :** Respecter patterns existants (loaders, versioning)
4. **Vérifier :** `npm run assets:diff`, Lighthouse > 90
## Checklist
**Images :**
- [ ] Compressées (TinyPNG/Squoosh)
- [ ] WebP + fallback PNG/JPG
- [ ] Responsive si > 50 KB (srcset)
- [ ] Lazy loading si hors-viewport
- [ ] Alt text présent
- [ ] Versioning cache-updater.js
**Audio :**
- [ ] Bitrate optimisé (96-128 kbps)
- [ ] Formats multiples (MP3 + OGG)
- [ ] < 50 KB par fichier
- [ ] Preload si critique
**Général :**
- [ ] assets:analyze exécuté
- [ ] assets:diff vérifié
- [ ] Lighthouse > 90
- [ ] First load < 2 MB
## En cas de doute
**Règles absolues :**
1. Compresse TOUJOURS (TinyPNG/Squoosh)
2. WebP + fallback PNG/JPG
3. Versioning via cache-updater.js
4. Lighthouse > 90 OBLIGATOIRE
**Outils :**
- TinyPNG/Squoosh - Compression (web)
- ffmpeg - Audio/vidéo (CLI)
- Lighthouse - Vérification
**Modules clés :**
- responsive-image-loader.js (9 KB)
- cache-updater.js (10 KB)
- npm run assets:\*
**Où chercher :**
- responsive-image-loader.js - Chargement images
- cache-updater.js - Versioning
- assets/ - Organisation actuelle
- npm run assets:analyze - État

View File

@@ -0,0 +1,124 @@
---
name: profiling-performance
description: Analyzes and optimizes application performance (loading time, FPS, memory, bottlenecks). Use when experiencing slowdowns, before releases, or optimizing arcade games
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Profileur de Performance
Analyse et optimise performances pour expérience utilisateur fluide (chargement, FPS, mémoire).
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Métriques cibles](#métriques-cibles)
- [Outils d'analyse](#outils-danalyse)
- [Zones de profiling](#zones-de-profiling)
- [Patterns essentiels](#patterns-essentiels)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ralentissements dans les jeux
- Avant chaque release majeure
- Ajout de features lourdes
- Optimisation FPS arcade
- Investigation memory leaks
- Mobile performance
## Métriques cibles
**Chargement :** FCP < 1.5s, TTI < 3s, TBT < 200ms
**Runtime :** FPS ≥ 60 (arcade), Memory < 50 MB (stable)
**Bundle :** Initial < 200 KB (gzipped), Total < 2 MB
## Outils d'analyse
**Chrome DevTools Performance :**
- Profile JS (Scripting), Rendering, Painting
- Identifie Long Tasks (> 50ms = problème)
- Mesure FPS en temps réel
**Lighthouse :**
- Performance > 90, Accessibility > 95, PWA > 90
- Identifie bottlenecks chargement
**Performance API :**
- `performance.mark()` / `performance.measure()`
- `performance.getEntriesByName()` pour résultats
## Zones de profiling
### 1. Chargement initial
- Lighthouse audit → FCP, TTI
- Lazy loading modules lourds (trouvé dans lazy-loader.js)
- Imports dynamiques existants
### 2. FPS arcade (< 60 FPS = problème)
- Trop de calculs dans game loop → cacher résultats
- Re-render inutiles → cherche dirty rectangles/layers
- DOM excessif → batch avec requestAnimationFrame
### 3. Memory leaks
- DevTools Memory → Heap snapshots
- Event listeners non nettoyés dans cleanup()
- Timers non clearés (setInterval/clearInterval)
### 4. Bundle size
- Scripts npm : analyze:dependencies, dead-code
- Lazy-loader configuration
- Code splitting opportunities
## Patterns essentiels
- **Debounce/Throttle :** Événements fréquents
- **Memoization :** Cache résultats coûteux
- **requestAnimationFrame :** Batch DOM updates
- **Lazy loading :** Modules > 50 KB
- **Cleanup :** Listeners/Timers en destroy
## Workflow
1. **Identifier :** Profile DevTools ou Lighthouse
2. **Mesurer :** Taille, FPS, TTI avant optimisation
3. **Optimiser :** Une stratégie à la fois
4. **Valider :** Re-mesure, seuils atteints, mobile OK
## Checklist
- [ ] Lighthouse Performance > 90
- [ ] FPS ≥ 60 (arcade)
- [ ] Lazy loading implémenté
- [ ] Cleanup() nettoyage complet
- [ ] Memory leak-free (heap snapshot stable)
- [ ] Bundle < 200 KB initial
- [ ] Debounce/throttle sur événements
- [ ] Assets optimisés
## En cas de doute
**Workflow minimal :**
```bash
# Profile avec DevTools ou Lighthouse
# Identifier bottleneck (chargement, FPS, mémoire)
# Appliquer pattern (lazy loading > debounce > cache)
# Mesurer avant/après
# Valider sur mobile (bas de gamme)
```
**Règles absolues :**
1. Profile d'abord, optimiser après
2. Mesure avant/après
3. Une optimisation à la fois
4. Tests passent

View File

@@ -0,0 +1,167 @@
---
name: practicing-tdd-with-jest
description: Implements features following Test-Driven Development RED/GREEN/REFACTOR cycle with Jest. Use when adding new features, fixing bugs, or refactoring existing code
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Test-Driven Development avec Jest
Implémente code en suivant cycle TDD RED/GREEN/REFACTOR avec Jest.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Cycle TDD : RED → GREEN → REFACTOR](#cycle-tdd--red--green--refactor)
- [Scripts npm](#scripts-npm)
- [Structure tests (Arrange-Act-Assert)](#structure-tests-arrange-act-assert)
- [Assertions Jest essentielles](#assertions-jest-essentielles)
- [Mocking](#mocking)
- [Tests spécialisés](#tests-spécialisés)
- [Couverture](#couverture)
- [Bonnes pratiques](#bonnes-pratiques)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Implémentation nouvelles features
- Correction bugs avec reproduction
- Refactoring code existant
- Ajout comportements modules
- Validation logique complexe
## Cycle TDD : RED → GREEN → REFACTOR
**RED (Test échoue) :**
1. Identifier comportement
2. Écrire test AVANT code
3. Test DOIT échouer ❌
**GREEN (Test passe) :**
1. Code minimum possible
2. Pas d'optimisation/généralisation
3. Faire passer test uniquement ✅
**REFACTOR (Améliorer) :**
1. Nettoyer code (noms, structure)
2. Éliminer duplications
3. Vérifier tests passent toujours ✅
## Scripts npm
- `npm test` - Tous tests
- `npm run test:watch` - Mode watch
- `npm run test:coverage` - Avec couverture
## Structure tests (Arrange-Act-Assert)
**AAA Pattern :**
- **Arrange :** Préparer données
- **Act :** Exécuter action
- **Assert :** Vérifier résultat
**Grouping :**
- `describe()` - Grouper tests liés
- `test()` / `it()` - Tests individuels
- `beforeEach()` / `afterEach()` - Setup/cleanup
**Nommage :** Descriptif ("should do X when Y", "handles edge case Z")
## Assertions Jest essentielles
- Égalité: `toBe()` (strict), `toEqual()` (profonde)
- Booléens: `toBeTruthy()`, `toBeFalsy()`, `toBeNull()`, `toBeUndefined()`
- Nombres: `toBeGreaterThan()`, `toBeLessThan()`, `toBeCloseTo()`
- Arrays: `toContain()`, `toHaveLength()`
- Exceptions: `toThrow()`, `toThrow(ErrorClass)`
Voir documentation Jest pour liste complète.
## Mocking
**Fonctions :**
- `jest.fn()` - Mock simple
- `mockReturnValue()` - Valeur
- `mockResolvedValue()` / `mockRejectedValue()` - Promesses
- `toHaveBeenCalled()`, `toHaveBeenCalledWith(args)`, `toHaveBeenCalledTimes(n)`
**Modules :** Isoler code testé, éviter dépendances externes (API, localStorage)
## Tests spécialisés
**Async :** `async/await` recommandé, ou `expect().resolves/rejects`
**DOM/UI :** jsdom simule DOM - créer, attacher, exécuter, vérifier, cleanup
**Canvas (jeux arcade) :** Mock context, mock performance.now(), tester logique séparément rendu, tests d'état
## Couverture
**Cibles :** Branches > 80%, Functions > 80%, Lines > 80%, Statements > 80%
Lance `npm run test:coverage`, examine rapport.
## Bonnes pratiques
**Do's :**
- Test AVANT code TOUJOURS
- Un test à la fois (RED → GREEN → REFACTOR)
- Tests descriptifs (noms clairs)
- Isolés, indépendants
- Edge cases (null, undefined, limites)
- Rapides (< 100ms idéal)
**Don'ts :**
- Pas de code avant test
- Pas de tests trop larges
- Pas de tests fragiles (timing, random)
- Pas de RED ignoré (test inutile)
- Pas de .skip tests
## Workflow
1. **Requirement :** Cas normaux + edge cases
2. **Test RED :** Doit échouer
3. **Code GREEN :** Minimum pour passer
4. **REFACTOR :** Améliorer, tests verts
5. **Répéter :** Couverture > 80%
## Checklist
- [ ] Test écrit AVANT code
- [ ] Test échoue (RED)
- [ ] Code minimum
- [ ] Test passe (GREEN)
- [ ] Refactorisé si besoin
- [ ] Noms descriptifs
- [ ] AAA pattern
- [ ] Mocks isolent
- [ ] Edge cases
- [ ] Couverture > 80%
- [ ] Tests rapides
## En cas de doute
**Règles absolues :**
1. Cycle RED → GREEN → REFACTOR OBLIGATOIRE
2. Test doit échouer d'abord (sinon inutile)
3. Code minimum (pas sur-engineering)
4. Refactor après GREEN seulement
5. Tests restent verts après refactor
6. Couverture > 80%
**Références :**
- Tests existants patterns
- jest.config.cjs - Configuration
- npm run test:coverage - État actual

View File

@@ -0,0 +1,94 @@
---
name: managing-pwa-service-worker
description: Manages Service Worker updates securely with cache versioning and offline tests. Use when modifying SW, adding resources, or changing cache strategy
allowed-tools: Read, Write, Grep, Glob, Bash
---
# PWA Service Worker Manager
Gère Service Worker pour offline play et cache versioning sécurisé.
## Quand utiliser
- Modification Service Worker
- Ajout ressources à cacher
- Changement stratégie cache
- Tests offline
- Correction bugs SW
## Scripts essentiels
```bash
npm run test:pwa-offline # Tester offline (PRINCIPAL)
npm run sw:disable # Désactiver SW
npm run sw:fix # Réparer SW
```
## Versioning et workflow
**SemVer (voir sw.js) :**
- Major : Changements cassants
- Minor : Ressources ajoutées
- Patch : Corrections
**Workflow :**
1. **Modifier :** sw.js (version, ressources, handlers)
2. **Incrémenter :** Version (SemVer)
3. **Tester :** `npm run test:pwa-offline`
4. **Vérifier :** DevTools App tab (Offline mode)
5. **Quality :** format:check, lint, test
## Stratégies de cache
- **Cache First :** Assets (HTML, CSS, JS, images)
- **Network First :** APIs (données fraîches)
- **Cache Only :** Assets immuables
- **Network Only :** Analytics, auth
Trouve stratégie dans sw.js existant.
## Événements SW clés
- **Install :** Créer cache, skipWaiting()
- **Activate :** Nettoyer anciens caches, clients.claim()
- **Fetch :** Appliquer stratégie, gérer erreurs
## Debugging
**Chrome DevTools (F12) → Application → Service Workers :**
- Offline mode → Tester navigation
- caches.keys() en console → Vérifier caches
**Problèmes courants :**
- SW ne s'update → Incrémenter version, skipWaiting() présent
- Ressources manquantes → Ajouter à liste cache
- Cache volumineux → Cacher uniquement ressources critiques
## Checklist
- [ ] Version incrémentée (SemVer)
- [ ] skipWaiting() + clients.claim() présents
- [ ] Nettoyage anciens caches
- [ ] Offline test OK (`npm run test:pwa-offline`)
- [ ] DevTools Offline mode OK
- [ ] format:check, lint, test passent
## En cas de doute
**Règles absolues :**
1. Incrémenter version TOUJOURS
2. Tester offline AVANT commit
3. DevTools Application tab verification
4. `npm run test:pwa-offline` doit passer
5. skipWaiting() + clients.claim() essentiels
**Références :**
- `sw.js` - Service Worker principal
- `manifest.json` - PWA manifest
- Chrome DevTools Application tab

View File

@@ -0,0 +1,126 @@
---
name: reporting-accessibility-audit
description: Standardized template for WCAG 2.1 AA accessibility audit reports. Use when generating accessibility audit outputs.
---
# Rapport d'audit d'accessibilité : [Nom de la fonctionnalité/page]
## Résumé
**Conformité WCAG 2.1 AA** : ✅ CONFORME | ⚠️ PARTIEL | ❌ NON CONFORME
**Problèmes critiques** : [nombre]
**Problèmes importants** : [nombre]
**Suggestions** : [nombre]
**Évaluation globale** : [Résumé d'une phrase]
## Score de conformité WCAG 2.1
| Principe | Score | Statut |
| ------------------ | ------- | -------- |
| **Perceptible** | [X]/100 | ✅/⚠️/❌ |
| **Utilisable** | [X]/100 | ✅/⚠️/❌ |
| **Compréhensible** | [X]/100 | ✅/⚠️/❌ |
| **Robuste** | [X]/100 | ✅/⚠️/❌ |
| **Global** | [X]/100 | ✅/⚠️/❌ |
---
## Problèmes critiques 🔴 (À corriger)
### [Titre du problème]
**Critère WCAG** : [X.X.X Niveau AA]
**Impact** : Élevé - Empêche l'accès pour [groupe d'utilisateurs]
**Emplacement** : `[fichier:ligne]` ou [Page/Composant]
**Problème** :
[Description détaillée du problème]
**Code actuel** :
```html
[Code problématique]
```
**Recommandation** :
```html
[Code corrigé]
```
**Utilisateurs affectés** :
[Qui est impacté : utilisateurs de clavier, utilisateurs de lecteurs d'écran, etc.]
---
## Problèmes importants 🟠 (Devrait être corrigé)
[Même format que les problèmes critiques]
---
## Suggestions 🟡 (Agréable à avoir)
[Même format que les problèmes critiques]
---
## Audit de la navigation au clavier
**Statut** : ✅ EXCELLENT | ⚠️ PROBLÈMES TROUVÉS | ❌ CASSÉ
**Ordre de tabulation** : ✅ Logique | ⚠️ Problèmes | ❌ Cassé
**Indicateurs de focus** : ✅ Visibles | ⚠️ Incohérents | ❌ Manquants
**Pièges à clavier** : ✅ Aucun | ❌ Trouvé [nombre]
---
## Compatibilité avec les lecteurs d'écran
**NVDA (Windows)** : ✅ Compatible | ⚠️ Problèmes | ❌ Cassé
**VoiceOver (macOS)** : ✅ Compatible | ⚠️ Problèmes | ❌ Cassé
**Utilisation d'ARIA** :
- Étiquettes : ✅ Appropriées | ⚠️ Problèmes | ❌ Manquantes
- Points de repère : ✅ Présents | ⚠️ Incomplets | ❌ Manquants
- Régions live : ✅ Fonctionnelles | ⚠️ Problèmes | ❌ Manquantes
---
## Analyse des couleurs et du contraste
**Statut** : ✅ CONFORME | ⚠️ PROBLÈMES TROUVÉS | ❌ NON CONFORME
| Élément | Premier plan | Arrière-plan | Ratio | Requis | Statut |
| ------------ | ------------ | ------------ | ----- | ------ | ------ |
| Texte normal | #XXXXXX | #XXXXXX | X.X:1 | 4.5:1 | ✅/❌ |
| Grand texte | #XXXXXX | #XXXXXX | X.X:1 | 3:1 | ✅/❌ |
---
## Actions à entreprendre
### Must Fix (Bloquant - Violations WCAG)
1. [Problème d'accessibilité critique 1]
### Should Fix (Haute Priorité)
1. [Problème d'accessibilité important 1]
---
## Liste de contrôle de conformité
- [ ] Tous les éléments interactifs sont accessibles au clavier
- [ ] Les indicateurs de focus sont visibles et clairs
- [ ] Pas de pièges à clavier
- [ ] Les étiquettes ARIA sont présentes et précises
- [ ] Le contraste des couleurs respecte WCAG AA
- [ ] L'information ne repose pas uniquement sur la couleur
- [ ] Les images ont un texte alternatif
- [ ] Les entrées de formulaire ont des étiquettes
- [ ] Les messages d'erreur sont accessibles
- [ ] Les cibles tactiles sont ≥ 44x44px
**Verdict final** : ✅ CONFORME WCAG 2.1 AA | ⚠️ CONFORME SOUS CONDITIONS | ❌ NON CONFORME

View File

@@ -0,0 +1,72 @@
---
name: reporting-arcade-game-analysis
description: Standardized template for arcade game analysis reports with performance and gameplay metrics. Use when generating arcade game analysis outputs.
---
# Analyse du jeu d'arcade : [Nom du jeu]
## Résumé
**Statut** : ✅ OPTIMAL | ⚠️ ACCEPTABLE | ❌ PROBLÈMES CRITIQUES TROUVÉS
**FPS cible** : 60
**FPS mesuré** : [Valeur FPS moyenne]
**Budget de trame** : 16,6 ms par trame
**Temps de trame réel** : [Moyenne en ms]
**Utilisation de la mémoire** : [Mo]
**Performances de collision** : [vérifications par trame]
[Bref aperçu de 2 à 3 phrases de l'état du jeu et des principales conclusions]
## Analyse des performances
### Performances de rendu
**État actuel** :
- Appels de dessin par image : [nombre]
- Taille du canevas : [largeur x hauteur]
- Couches utilisées : [nombre]
- Mise en cache des sprites : [Oui/Non]
**Conclusions** :
- ✅ Efficace : [Lister les aspects optimisés]
- ⚠️ Préoccupations : [Lister les problèmes potentiels]
- ❌ Problèmes : [Lister les problèmes critiques]
### Performances de la détection de collision
**État actuel** :
- Algorithme : [AABB / Cercle / Au pixel près / Partitionnement spatial]
- Vérifications par trame : [nombre]
- Complexité : [O(n), O(n²), O(n log n)]
**Conclusions** :
[Analyse détaillée de l'efficacité de la détection de collision]
## Recommandations d'optimisation
### Critique (À corriger) - Impact : Élevé, Effort : [Faible/Moyen/Élevé]
1. **[Titre du problème]**
- **Problème** : [Description]
- **Impact** : [Chute de FPS, fuite de mémoire, etc.]
- **Solution** :
```javascript
// Avant
[Code problématique actuel]
// Après
[Code optimisé]
```
### Important (Devrait être corrigé) - Impact : Moyen, Effort : [Faible/Moyen/Élevé]
[Même structure que Critique]
## Prochaines étapes
1. **Immédiat** : [Corrections critiques à mettre en œuvre]
2. **À court terme** : [Améliorations importantes]

View File

@@ -0,0 +1,78 @@
---
name: reporting-code-review
description: Standardized template for code review reports with severity classification. Use when generating code review outputs.
---
# Revue de code : [Nom de la fonctionnalité/du composant]
## Résumé
**Évaluation globale** : ✅ APPROUVÉ | ⚠️ APPROUVÉ AVEC COMMENTAIRES | ❌ MODIFICATIONS REQUISES
**Fichiers révisés** : [Nombre] fichiers
**Problèmes trouvés** : 🔴 [X] Critiques | 🟠 [Y] Importants | 🟡 [Z] Suggestions
**Points positifs** : [Nombre] bonnes pratiques
---
## Problèmes critiques 🔴 (Doit être corrigé)
### [Titre du problème]
**Gravité** : Critique
**Emplacement** : `[chemin du fichier]:[numéro de ligne]`
**Catégorie** : Sécurité | Performances | Modification avec rupture
**Problème** :
[Description claire du problème]
**Impact** :
[Explication des conséquences]
**Recommandation** :
```javascript
// ❌ Actuel (problématique)
[code actuel]
// ✅ Correctif recommandé
[code corrigé]
```
---
## Problèmes importants 🟠 (Devrait être corrigé)
[Même format que les problèmes critiques]
---
## Suggestions 🟡 (À considérer)
[Même format que les problèmes critiques]
---
## Points positifs 🟢
### [Bonne pratique 1]
**Emplacement** : `[chemin du fichier]:[numéro de ligne]`
**Pourquoi c'est bien** : [Explication]
---
## Résumé des modifications requises
### Doit être corrigé (Bloquant)
1. [Problème critique 1]
### Devrait être corrigé (Haute priorité)
1. [Problème important 1]
---
## Approbation
**Décision finale** : ✅ APPROUVÉ | ⚠️ APPROUVÉ SOUS CONDITIONS | ❌ REJETÉ

View File

@@ -0,0 +1,72 @@
---
name: reporting-debug-session
description: Standardized template for debugging session reports with root cause analysis. Use when generating debug reports.
---
# Rapport de débogage : [Titre du bogue]
## Résumé
**Statut** : ✅ RÉSOLU | ⚠️ SOLUTION DE CONTOURNEMENT TROUVÉE | 🔍 EN COURS | ❌ BLOQUÉ
**Gravité** : 🔴 Critique | 🟠 Élevée | 🟡 Moyenne | 🟢 Faible
## Description du bogue
**Symptôme** : [Ce qui échoue/est cassé]
**Environnement** :
- Navigateur: [Version du navigateur]
- Appareil: [Type d'appareil]
- SE: [Système d'exploitation]
**Étapes pour reproduire** :
1. [Étape 1]
2. [Étape 2]
**Comportement attendu** : [Ce qui devrait se passer]
**Comportement réel** : [Ce qui se passe réellement]
## Analyse de la cause racine
### Cause immédiate
**Ce qui a échoué** : [Le code/composant immédiat qui a échoué]
**Emplacement** : `[chemin du fichier]:[numéro de ligne]`
### Cause première
**Pourquoi ça a échoué** : [Explication approfondie du problème sous-jacent]
## Le correctif
### Solution implémentée
**Approche** : [Description de haut niveau du correctif]
**Modifications du code** :
```javascript
// ❌ AVANT (bogué)
[ancien code]
// ✅ APRÈS (corrigé)
[nouveau code]
```
### Pourquoi ce correctif fonctionne
[Explication de la manière dont le correctif résout la cause première]
## Vérification
- [x] Le cas de reproduction original est corrigé
- [x] Un test de régression a été ajouté
- [x] Les tests du projet passent (`npm test`)
## Recommandations de prévention
1. [Action 1 pour prévenir la récurrence immédiate]
2. [Amélioration à long terme (ex: architecture, tests)]

View File

@@ -0,0 +1,35 @@
---
name: reporting-devtools-test
description: Standardized template for Chrome DevTools browser testing reports. Use when generating DevTools test outputs.
---
# Rapport de test : [Nom de la fonctionnalité]
## Résumé
**Statut** : ✅ RÉUSSI | ❌ ÉCHEC | ⚠️ PARTIEL
**Évaluation globale** : [Résumé d'une ligne]
## Sortie de la console
[Lister toutes les erreurs, avertissements et journaux pertinents trouvés]
## Analyse du réseau
[Rapport sur les requêtes ayant échoué, le chargement lent, les problèmes d'API]
## Résultats des tests fonctionnels
[Résultats des tests de fonctionnalités et des interactions utilisateur]
## Problèmes visuels/d'interface utilisateur
[Problèmes de mise en page, problèmes de conception réactive, problèmes d'accessibilité]
## Métriques de performance
[Temps de chargement, performances de rendu, utilisation de la mémoire]
## Recommandations
[Correctifs ou améliorations spécifiques nécessaires, le cas échéant]

View File

@@ -0,0 +1,43 @@
---
name: reporting-i18n-coordination
description: Standardized template for internationalization coordination reports. Use when generating i18n synchronization outputs.
---
# Rapport de coordination i18n : [Nom de la fonctionnalité/du module]
## Résumé
**Statut** : ✅ SYNCHRONISÉ | ⚠️ PROBLÈMES MINEURS | ❌ SYNCHRONISATION REQUISE
**Langues** : fr (référence), en, es
**Total des clés** : [Nombre dans fr.json]
**Clés manquantes** : [Total manquant]
**Valeurs vides** : [Total]
---
## Analyse de la couverture
### Anglais (en.json)
- **Statut** : ✅ Synchronisé | ⚠️ Problèmes mineurs | ❌ Problèmes critiques
- **Problèmes trouvés** : [Lister les problèmes]
### Espagnol (es.json)
- **Statut** : ✅ Synchronisé | ⚠️ Problèmes mineurs | ❌ Problèmes critiques
- **Problèmes trouvés** : [Lister les problèmes]
---
## Actions de correction
### Correctifs critiques (Doivent être implémentés)
1. **[Titre du correctif]**
- **Fichiers à modifier** : `i18n/en.json`
- **Action** : [Description de l'action, ex: "Ajouter les X clés manquantes suivantes..."]
### Améliorations (Devraient être implémentées)
1. **[Titre de l'amélioration]**
- **Action** : [Description, ex: "Supprimer les X clés orphelines..."]

View File

@@ -0,0 +1,48 @@
---
name: reporting-performance-analysis
description: Standardized template for performance analysis reports with Lighthouse metrics. Use when generating performance analysis outputs.
---
# Analyse des performances : [Nom du composant/de la page]
## Résumé
**Statut** : ✅ OPTIMAL | ⚠️ A BESOIN D'AMÉLIORATION | ❌ PROBLÈMES CRITIQUES TROUVÉS
**Score Lighthouse** : [Valeur]/100
**LCP** : [Valeur]s (Cible : < 2.5s) [✅|⚠️|❌]
**CLS** : [Valeur] (Cible : < 0.1) [✅|⚠️|❌]
**TBT** : [Valeur]ms (Cible : < 200ms) [✅|⚠️|❌]
---
## Analyse des Core Web Vitals
### Largest Contentful Paint (LCP) : [Valeur]s
- **Élément LCP** : [Description de l'élément]
- **Opportunités d'optimisation** : [Recommandation 1], [Recommandation 2]
### Cumulative Layout Shift (CLS) : [Valeur]
- **Éléments problématiques** : [Lister les éléments causant un décalage]
- **Correctifs suggérés** : [Suggestions pour réserver de l'espace ou optimiser le chargement]
### Total Blocking Time (TBT) : [Valeur]ms
- **Tâches longues identifiées** : [Lister les scripts ou fonctions bloquantes]
- **Stratégies d'optimisation** : [Suggestions pour diviser les tâches ou différer le code]
---
## Goulots d'étranglement des performances
### Critique (À corriger immédiatement)
1. **[Titre du problème]**
- **Impact sur la métrique** : [Métrique spécifique affectée et de combien]
- **Cause racine** : [Explication technique]
- **Solution suggérée** : [Description du correctif]
### Important (À corriger bientôt)
[Même structure que Critique]

View File

@@ -0,0 +1,47 @@
---
name: reporting-pwa-audit
description: Standardized template for Progressive Web App audit reports with offline and service worker checks. Use when generating PWA audit outputs.
---
# Rapport d'audit PWA : [Nom de la fonctionnalité/modification]
## Résumé
**Statut général** : ✅ PRÊT POUR LA PRODUCTION | ⚠️ PROBLÈMES TROUVÉS | ❌ NON PRÊT
**Scores Lighthouse** : Performance [X], PWA [X], Accessibilité [X]
**Fonctionnalité hors ligne** : ✅ OUI | ❌ NON
---
## Analyse du Service Worker
- **Statut** : ✅ OPTIMAL | ⚠️ A BESOIN D'AMÉLIORATION | ❌ CASSÉ
- **Stratégie de cache** : [cache-first/network-first]
- **Problèmes trouvés** : [Lister les problèmes de SW]
---
## Fonctionnalité hors ligne
- **Statut** : ✅ FONCTIONNE PARFAITEMENT | ⚠️ PARTIEL | ❌ CASSÉ
- **Scénarios testés** : [Chargement initial, navigation, jeu hors ligne]
- **Problèmes** : [Lister les problèmes hors ligne]
---
## Manifeste d'application Web
- **Statut** : ✅ VALIDE | ⚠️ INCOMPLET | ❌ INVALIDE
- **Checklist** : [name, short_name, icons, display: standalone, etc.]
---
## Actions à entreprendre
### Doit être corrigé (Bloquant)
1. [Problème critique 1]
### Devrait être corrigé (Haute priorité)
1. [Problème important 1]

View File

@@ -0,0 +1,43 @@
---
name: reporting-test-writing
description: Standardized template for test writing reports with coverage metrics. Use when generating test writing outputs.
---
# Rapport de test : [Nom de la fonctionnalité/du composant]
## Résumé
**Tests écrits** : [Nombre] tests
**Couverture** : [Pourcentage]%
**Conformité TDD** : ✅ Tous les tests écrits avant l'implémentation
**Statut** : ✅ COMPLET
---
## Détails de la couverture des tests
### Tests unitaires
- [Fonctionnalité 1] : [X] tests ([couverture]%)
- [Fonctionnalité 2] : [Y] tests ([couverture]%)
### Cas limites couverts
- [Cas limite 1]
- [Cas limite 2]
---
## Cas de test notables
### [Titre du cas de test]
**Scénario** : [Description]
**Pourquoi c'est important** : [Explication]
---
## Stratégie de simulation
- **Simulé** : [Liste des dépendances simulées et pourquoi]
- **Non simulé** : [Liste des implémentations réelles et pourquoi]

View File

@@ -0,0 +1,37 @@
---
name: reporting-web-research
description: Standardized template for web research reports with source citations. Use when generating web research outputs.
---
# Rapport de recherche web
## Résumé de la recherche
[Bref aperçu de 2 à 3 phrases de ce que vous avez trouvé]
---
## Principales conclusions
### [Sujet/Section 1]
[Informations détaillées avec exemples]
### [Sujet/Section 2]
[Informations détaillées avec exemples]
---
## Sources
[Liste des URL et des références consultées, avec brèves descriptions]
- [Source 1] : [URL] - [Brève description]
- [Source 2] : [URL] - [Brève description]
---
## Recommandations
[Le cas échéant, fournir des recommandations exploitables basées sur votre recherche]

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)

View File

@@ -0,0 +1,87 @@
---
name: managing-sound-effects
description: Manages sound effects and audio for user feedback (correct/wrong sounds, music, volume). Use when adding new sounds or managing audio
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Sound Effect Manager
Gère effets sonores et feedback audio pour meilleure expérience utilisateur.
## Quand utiliser
- Ajout de nouveaux effets sonores
- Gestion du volume et mute
- Musique de fond pour jeux
- Feedback audio utilisateur
- Optimisation chargement audio
## AudioManager (js/core/audio.js)
**API :**
- `playSound(soundName, options)` - Jouer son
- `setVolume(volume)` - Volume global (0.0-1.0)
- `toggleMute()` / `isMuted()` - Mute control
**Sons disponibles (examine audio.js) :**
correct, wrong, victory, click, coin, levelup
## Ajouter un nouveau son
1. **Compresser :** < 50 KB (96 kbps pour effets, 128 kbps musique)
2. **Formats :** MP3, OGG, WebM (fallback)
3. **Placer :** assets/sounds/
4. **Enregistrer :** SOUND_CATALOG dans audio.js
5. **Utiliser :**
```javascript
import { playSound } from './core/audio.js';
playSound('yourSound');
```
## Patterns essentiels
- **Préchargement :** Sons critiques avant utilisation
- **Pool audio :** Instances multiples pour chevauchement
- **Musique fond :** Volume 0.3, loop activé, cleanup dans destroy
- **Mobile :** Autoplay nécessite interaction utilisateur
- **Accessibilité :** Respecter prefers-reduced-motion
## Gestion du lifecycle
**Mode avec musique :**
```javascript
// Lancer musique
playSound('background-music', { loop: true, volume: 0.3 });
// cleanup() → stopper musique
```
Examine QuizMode/ChallengeMode pour patterns existants.
## Checklist ajout son
- [ ] Fichier compressé < 50 KB
- [ ] Formats multiples (MP3, OGG, WebM)
- [ ] Ajouté au SOUND_CATALOG
- [ ] Volume testé
- [ ] Mute fonctionne
- [ ] Cleanup musique si loop
- [ ] Mobile autoplay OK
## En cas de doute
**Règles absolues :**
1. Utiliser audio.js API (jamais créer Audio directement)
2. < 50 KB par fichier
3. Stopper musique dans cleanup()
4. Pas d'autoplay sans interaction utilisateur
5. Volume par défaut ≤ 0.7
**Référence :**
- `js/core/audio.js` - API complète
- `assets/sounds/` - Catalogues existants
- Modes (QuizMode, ChallengeMode) - Exemples d'utilisation

View File

@@ -0,0 +1,212 @@
---
name: managing-sprites
description: Manages sprites, sprite sheets, sprite animations for arcade games (loading, rendering, collisions). Use when creating games or adding animated characters
allowed-tools: Read, Write, Grep, Glob, Bash
---
# Gestion des Sprites
Guide la gestion des sprites et sprite sheets pour les jeux arcade.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Sprites dans le projet](#sprites-dans-le-projet)
- [Types de sprites](#types-de-sprites)
- [Concepts clés](#concepts-clés)
- [Classes et structures recommandées](#classes-et-structures-recommandées)
- [Optimisations](#optimisations)
- [Workflow de création sprite](#workflow-de-création-sprite)
- [Checklist sprite](#checklist-sprite)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout de nouveaux personnages/ennemis
- Création de sprite sheets
- Animations de sprites
- Détection de collisions
- Optimisation rendu sprites
## Sprites dans le projet
Trouve dans le code :
- Personnages joueurs
- Monstres et ennemis
- Power-ups et collectibles
- Sprite sheets existants
**Formats :**
- PNG avec transparence
- Sprite sheets (multiples frames)
- Résolutions multiples (@1x, @2x, @3x)
Examine le répertoire assets/sprites.
## Types de sprites
### 1. Sprite simple
Image statique, pas d'animation, position et taille fixes.
### 2. Sprite Sheet
**Multiple frames dans une image :**
- Layout horizontal (frames en ligne)
- Layout grille (frames en grille)
- Permet animations fluides
**Layouts courants :**
- Horizontal : 8 frames × 64px = 512×64px
- Grille 4×4 : 16 frames de 64×64px = 256×256px
- Par row : Chaque ligne = animation différente
Trouve les sprite sheets existants.
### 3. Sprite animé
**Animation frame par frame :**
- FPS configurable
- Boucle automatique
- Delta time pour smoothness
### 4. Sprite directionnel
**Différentes animations par direction :**
- Idle, Walk, Jump par direction
- Row dans sprite sheet par action
- State machine pour transitions
## Concepts clés
### Chargement d'images
**Asynchrone :**
- `Image.onload` pour savoir quand prêt
- Précharger avant utilisation
- Placeholder ou loading si nécessaire
Trouve comment le projet gère le chargement.
### Rendering
**Canvas drawImage() :**
- Source rectangle (quelle partie du sprite sheet)
- Destination rectangle (où dessiner)
- Scaling automatique si tailles différentes
Examine les fonctions de rendu dans les jeux.
### Collision Detection
**Techniques disponibles :**
- Bounding box (AABB) - Simple et rapide
- Collision circulaire - Pour objets ronds
- Pixel-perfect - Précis mais coûteux
- Hitbox personnalisée - Compromise
Trouve les fonctions de collision utilisées.
### Animation State Machine
**États et transitions :**
- IDLE → WALK → JUMP → FALL → IDLE
- Changement frame selon elapsed time
- Loop ou one-shot selon animation
Examine les state machines dans les jeux arcade.
## Classes et structures recommandées
Trouve dans le code :
- Classe Sprite de base
- Classe AnimatedSprite
- Manager de sprites (pool, loading)
- Helpers de collision
Examine l'architecture existante.
## Optimisations
### Performance
- **Sprite pooling** : Réutiliser instances au lieu de créer/détruire
- **Dirty flag** : Re-draw seulement si changement
- **Offscreen culling** : Pas de rendu si hors écran
- **Batch rendering** : Grouper draw calls
### Mémoire
- **Atlas textures** : Combiner sprites dans une texture
- **Lazy loading** : Charger sprites au besoin
- **Image scaling** : Charger résolution appropriée (@1x, @2x)
- **Cleanup** : Libérer sprites inutilisés
Cherche les optimisations déjà en place.
## Workflow de création sprite
### 1. Design sprite sheet
- Définir taille frame (64×64, 128×128, etc.)
- Organiser layout (horizontal, grille)
- Créer frames avec transparence PNG
### 2. Intégration code
- Charger sprite sheet
- Définir source rectangles par frame
- Setup animation (FPS, frames, loop)
- Render à chaque frame du jeu
### 3. Collision setup
- Définir hitbox pour collision
- Tester collisions avec autres sprites
- Ajuster hitbox si nécessaire
### 4. Tests et debug
- Afficher hitboxes en mode debug
- Vérifier timing animations
- Tester performance avec multiples sprites
## Checklist sprite
- [ ] Sprite sheet créé avec transparence PNG
- [ ] Layout défini (horizontal/grille)
- [ ] Frames chargées correctement
- [ ] Animations fluides (FPS approprié)
- [ ] Collisions détectées correctement
- [ ] Hitboxes ajustées
- [ ] Performance acceptable (60 FPS)
- [ ] Cleanup mémoire implémenté
## En cas de doute
**Source :** Jeux arcade existants + sprite utils
**Règles absolues :**
1. Toujours précharger sprites avant utilisation
2. Utiliser delta time pour animations fluides
3. Bounding box (AABB) pour la plupart des collisions
4. Sprite pooling si > 10 instances simultanées
5. Cleanup sprites inutilisés pour éviter memory leaks
**Workflow minimal :**
- Charger sprite sheet avec Image.onload
- drawImage() avec source/destination rectangles
- Collision AABB pour détection rapide

View File

@@ -0,0 +1,215 @@
---
name: testing-mobile-responsive
description: Tests mobile compatibility and responsive design (touch, viewports, mobile performance). Use after responsive CSS modifications, touch controls, or before releases
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Tests Responsive Mobile
Guide les tests de responsive design et compatibilité mobile pour garantir une expérience optimale sur tous les appareils.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Viewports essentiels](#viewports-essentiels)
- [Outils de test](#outils-de-test)
- [Checklist responsive](#checklist-responsive)
- [Workflow de test](#workflow-de-test)
- [Checklist finale](#checklist-finale)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Modifications CSS responsive
- Ajout de touch controls
- Avant chaque release
- Bugs reportés sur mobile
- Tests performance mobile
## Viewports essentiels
**Desktop:** 1920×1080, 1366×768
**Tablet:** 768×1024, 1024×768
**Mobile:** 375×667, 390×844, 412×915
Trouve les breakpoints CSS utilisés dans le projet.
## Outils de test
### Chrome DevTools Device Mode
Émule différents appareils :
- Viewports prédéfinis
- Touch simulation
- Network/CPU throttling
### Chrome DevTools MCP
- Capture screenshots multi-device
- Tests automatisés layout
- Performance profiling
### Tests sur vrais appareils
**Essentiels :**
- iPhone (iOS récent)
- Android (version récente)
**Pourquoi :**
- Touch réel ≠ simulation
- Performance réelle
- Bugs spécifiques device
## Checklist responsive
### 1. Layout
- Layout fluide (pas de horizontal scroll)
- Contenu lisible sans zoom
- Images redimensionnées
- Colonnes en stack mobile
### 2. Touch targets
**Taille minimum :**
- 44×44 px (iOS)
- 48×48 px (Android)
- 8px espacement minimum
Trouve les tailles de touch targets dans le CSS.
### 3. Navigation mobile
- Menu burger accessible
- Animation fluide
- Fermeture backdrop ou X
- Pas de piège clavier
### 4. Touch interactions
**Supportés :**
- Tap (pas de hover requis)
- Swipe si applicable
- Pinch-zoom si pertinent
**Éviter :**
- Hover-only interactions
- Gestures complexes
Trouve les touch handlers dans le JavaScript.
### 5. Formulaires mobiles
**Optimisations :**
- Input type approprié (`email`, `tel`, `number`)
- `autocomplete` actif
- Labels visibles
- Clavier adapté au type
Examine les formulaires et leur configuration.
### 6. Images responsive
**Techniques :**
- `srcset` pour résolutions multiples
- `<picture>` pour art direction
- Lazy loading
- WebP avec fallback
Trouve la stratégie d'images responsive.
### 7. Typography
**Tailles :**
- 16px minimum corps de texte
- Line-height ≥ 1.5
- rem/em pour scalabilité
Examine les tailles de police CSS.
### 8. Performance mobile
**Métriques cibles :**
- First Contentful Paint < 2s (3G)
- Time to Interactive < 5s (3G)
- Lighthouse Performance > 80
Lance Lighthouse en mode mobile.
## Workflow de test
### 1. Tests DevTools
Pour chaque viewport clé :
- Layout adaptatif
- Touch targets simulation
- Performance
- Screenshot
### 2. Tests vrais devices
iPhone et Android :
- Navigation complète
- Touch interactions réelles
- Formulaires
- Jeux arcade si applicable
### 3. Tests throttling
Avec 3G + 4x CPU :
- Temps de chargement
- Fluidité interactions
- FPS jeux arcade
### 4. Corrections
Priorise :
1. Bloquants (layout cassé)
2. UX dégradée (touch targets petits)
3. Performance (chargement lent)
## Checklist finale
- [ ] Tous viewports testés (mobile, tablet, desktop)
- [ ] Touch targets ≥ 44×44 px
- [ ] Pas de horizontal scroll
- [ ] Menu mobile fonctionnel
- [ ] Formulaires optimisés (input types)
- [ ] Images responsive (srcset/picture)
- [ ] Typography lisible (16px min)
- [ ] Performance 3G acceptable (< 5s TTI)
- [ ] Testé sur vrais appareils (iOS + Android)
- [ ] Lighthouse Mobile > 80
- [ ] Pas de hover-only interactions
## En cas de doute
**Source :** Vrais appareils + Lighthouse Mobile
**Règles absolues :**
1. Toujours tester sur vrais appareils (iOS + Android)
2. Toujours tester avec 3G throttling
3. Touch targets minimum 44×44 px
4. Jamais hover-only interactions
5. Lighthouse Mobile > 80 obligatoire
**Workflow minimal :**
- DevTools pour iterations rapides
- Vrais appareils pour validation finale
- Lighthouse mobile pour métriques

View File

@@ -0,0 +1,149 @@
---
name: testing-visual-regression
description: Visual regression tests for canvas games and responsive UI. Use after canvas modifications, CSS changes, or adding new arcade games
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Tests de Régression Visuelle
Détecte régressions visuelles dans jeux canvas et UI responsive via captures automatiques.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Ce que les tests visuels détectent](#ce-que-les-tests-visuels-détectent)
- [Architecture](#architecture)
- [Outils et Configuration](#outils-et-configuration)
- [Tests essentiels](#tests-essentiels)
- [Gestion des faux positifs](#gestion-des-faux-positifs)
- [Debugging](#debugging)
- [Workflow](#workflow)
- [Checklist](#checklist)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Modifications code canvas (jeux arcade)
- Changements CSS ou styles
- Ajout nouveau jeu arcade
- Avant release majeure
- Bugs visuels reportés
- Modifications thèmes
## Ce que les tests visuels détectent
**Tests unitaires NE détectent PAS:**
- Sprites mal positionnés/manquants
- Couleurs incorrectes
- Animations cassées
- Éléments mal alignés
- Responsive breakpoints cassés
- Thèmes mal appliqués
## Architecture
**Structure :**
- `baselines/` - Images de référence
- `current/` - Captures actuelles
- `diffs/` - Différences visuelles
**Viewports :**
- Desktop: 1920×1080
- Tablet: 768×1024
- Mobile: 375×667
Trouve structure tests visuels dans projet.
## Outils et Configuration
**Outils :** Playwright (visual testing intégré)
**Configuration clés :**
- Répertoire tests visuels
- Timeout canvas
- Retry sur timing
- Base URL serveur local
- Viewports configurés
Trouve ou crée configuration Playwright.
## Tests essentiels
**Jeux arcade (par jeu):**
- Écran démarrage
- Gameplay + action
- Game over
- États spécifiques
**UI responsive (par composant):**
- Dashboard, TopBar, Customization
- Chaque viewport (desktop, tablet, mobile)
- États interactifs (menus, toggles)
**Tolérance :**
- UI statique: maxDiffPixels 50-100
- Canvas animé: maxDiffPixels 200-300
- Responsive: maxDiffPixels 100
## Gestion des faux positifs
- **Animations :** Pause avant capture
- **Contenu dynamique :** Masquer avec option mask
- **Fonts :** Font smoothing cohérent
## Debugging
**Outils :**
- Rapport HTML (diffs visuels)
- Mode UI interactif (meilleur debug)
- Inspection manuelle diffs
**Images générées :**
- baseline (référence)
- actual (capture)
- diff (différences en rouge)
## Workflow
1. **Setup :** Installe Playwright, crée structure dossiers
2. **Tests arcade :** Start, gameplay, gameover
3. **Tests UI :** Tous viewports, états interactifs
4. **CI/CD :** Ajoute stage, bloque merge si régressions
5. **Review :** Examine diffs manuellement
## Checklist
- [ ] Desktop tests passent (1920×1080)
- [ ] Tablet tests passent (768×1024)
- [ ] Mobile tests passent (375×667)
- [ ] Baselines mises à jour (si intentionnel)
- [ ] Baselines commitées descriptif
- [ ] Pas de faux positifs
- [ ] Tolérance appropriée
- [ ] Diffs reviewed manuellement
## En cas de doute
**Règles absolues :**
1. Tests visuels OBLIGATOIRES après mods visuelles
2. Review manuellement TOUS diffs
3. Update baselines uniquement si intentionnel
4. Tolérance adaptée : statique strict, animé plus souple
5. Debug avec UI interactif
6. Baselines avec messages descriptifs
**Référence :**
- Structure baselines/ existante
- Scripts npm visual-testing
- Diffs générés (baseline/actual/diff)

View File

@@ -0,0 +1,167 @@
---
name: validating-accessibility
description: Validates web accessibility according to WCAG 2.1 AA standards for users with disabilities. Use when modifying UI, adding components, or performing accessibility audits
allowed-tools: Read, Grep, Glob, Bash, WebSearch
---
# Validateur d'Accessibilité
Guide la validation et l'amélioration de l'accessibilité web selon WCAG 2.1 niveau AA.
## Table des matières
- [Quand utiliser](#quand-utiliser)
- [Standards WCAG 2.1 AA](#standards-wcag-21-aa)
- [Scripts npm disponibles](#scripts-npm-disponibles)
- [Checklist essentielle](#checklist-essentielle)
- [Workflow d'audit](#workflow-daudit)
- [Checklist avant release](#checklist-avant-release)
- [En cas de doute](#en-cas-de-doute)
## Quand utiliser
- Ajout de composants UI
- Modification d'interfaces
- Avant chaque release majeure
- Audit d'accessibilité complet
## Standards WCAG 2.1 AA
**Quatre principes POUR :**
1. **Perceptible** - Information présentable
2. **Opérable** - Composants opérables
3. **Compréhensible** - Info et UI compréhensibles
4. **Robuste** - Contenu robuste
## Scripts npm disponibles
Trouve et utilise :
- Audit accessibilité complet
- Audit mobile responsive
- Vérification contraste
- Tests automatisés
## Checklist essentielle
### 1. Structure sémantique HTML
- Balises appropriées (`<header>`, `<nav>`, `<main>`, `<footer>`)
- Hiérarchie titres logique (h1 → h2 → h3)
- `<button>` pour actions, `<a>` pour navigation
### 2. Navigation clavier
- Éléments interactifs focusables
- Ordre tabulation logique
- Focus visible (outline ou custom)
- Raccourcis clavier sans conflit
### 3. ARIA (Accessible Rich Internet Applications)
**Utiliser quand sémantique HTML insuffisante**
Règles :
- Pas d'ARIA mieux que mauvais ARIA
- Vérifier support lecteurs d'écran
- Tester avec vraies technologies assistives
Attributs courants :
- `aria-label`, `aria-labelledby`
- `aria-describedby`
- `aria-hidden`
- `role` (button, dialog, alert, etc.)
### 4. Contraste couleurs
**WCAG 2.1 AA minimum :**
- Texte normal : 4.5:1
- Texte large (≥18pt ou ≥14pt gras) : 3:1
- Composants UI : 3:1
Outils : navigateur DevTools, Contrast Checker
### 5. Alternatives textuelles
- Toutes images avec `alt`
- Images décoratives : `alt=""`
- Images complexes : description détaillée
- Vidéos : sous-titres/transcription
### 6. Formulaires
- Labels explicites associés
- Messages d'erreur clairs
- Instructions visibles
- Validation côté client + serveur
### 7. Responsive et zoom
- Support zoom 200% sans perte fonctionnalité
- Contenu responsive (mobile, tablette, desktop)
- Touch targets ≥ 44×44 px mobile
## Workflow d'audit
### 1. Tests automatisés
Utilise scripts npm disponibles ou Lighthouse (Chrome DevTools).
### 2. Tests manuels
**Navigation clavier :**
- Tab à travers tous éléments interactifs
- Enter/Space pour activer
- Échap pour fermer modales/menus
**Lecteur d'écran :**
- VoiceOver (macOS/iOS)
- NVDA (Windows)
- JAWS (Windows)
**Contraste :**
- Vérifie tous textes et icônes
- Teste modes sombre/clair
### 3. Tests utilisateurs réels
- Personnes avec handicaps
- Différentes technologies assistives
- Feedback sur expérience réelle
## Checklist avant release
- [ ] Hiérarchie titres correcte
- [ ] Navigation clavier complète
- [ ] Contraste WCAG AA respecté
- [ ] Alt text sur toutes images
- [ ] Labels formulaires associés
- [ ] Focus visible partout
- [ ] Tests lecteur d'écran passés
- [ ] Zoom 200% fonctionnel
- [ ] Touch targets ≥ 44px mobile
## En cas de doute
**Source :** Standards WCAG 2.1 AA officiels
**Règles absolues :**
1. Toujours tester clavier uniquement
2. Toujours vérifier contraste
3. Toujours tester lecteur d'écran
4. Jamais cacher contenu sans `aria-hidden`
5. Jamais empêcher zoom mobile
**Workflow minimal :**
- Lighthouse audit
- Navigation clavier complète
- Test 1 lecteur d'écran minimum