Initial commit

2025-11-29 17:58:54 +08:00
commit 4d6408436e
32 changed files with 3539 additions and 0 deletions
--- a/commands/branch.md
+++ b/commands/branch.md
@@ -0,0 +1,152 @@
+---
+model: claude-sonnet-4-5-20250929
+allowed-tools: Bash
+argument-hint: <source-branch> [issue-number-or-text]
+description: Création de branche Git avec workflow structuré
+---
+
+# Création de branche Git
+
+## Purpose
+Créer une nouvelle branche Git de manière structurée avec support des issues GitHub.
+
+## Variables
+SOURCE_BRANCH: $1
+ISSUE_OR_TEXT: $2
+
+## Instructions
+- Utilise les outils Bash pour les opérations Git
+- Valide que la branche source existe
+- Génère un nom de branche basé sur l'issue si fournie
+- Applique les conventions de nommage du projet
+
+## Relevant Files
+- @.git/config
+- @.gitignore
+- @docs/README.md
+
+## Workflow
+
+**🚨 ÉTAPE CRITIQUE : CHECKOUT VERS SOURCE D'ABORD 🚨**
+
+1. **Vérifier SOURCE_BRANCH obligatoire**
+   - Si `SOURCE_BRANCH` n'est pas fourni → ARRÊTER et demander à l'utilisateur
+
+2. **Valider SOURCE_BRANCH existe localement**
+   - `git branch --list "$SOURCE_BRANCH"`
+   - Si n'existe pas → ARRÊTER avec erreur
+
+3. **🔴 CHECKOUT VERS SOURCE_BRANCH AVANT TOUT 🔴**
+   - `git checkout $SOURCE_BRANCH`
+   - Vérifier qu'on est bien dessus : `git branch --show-current`
+   - **CRITIQUE** : Cette étape garantit qu'on crée depuis un point propre
+
+4. **🔴 PULL POUR METTRE À JOUR SOURCE_BRANCH 🔴**
+   - `git pull origin $SOURCE_BRANCH`
+   - Garantit qu'on part du dernier commit de origin
+   - **CRITIQUE** : Évite de créer depuis un point obsolète
+
+5. **Générer nom de la nouvelle branche**
+   - Si `ISSUE_OR_TEXT` est fourni :
+     - Détecte si c'est un numéro (entier) ou du texte
+     - Si c'est un numéro :
+       - Récupère les informations de l'issue via GitHub CLI (`gh issue view ${ISSUE_OR_TEXT}`)
+       - Génère un nom de branche : `issue/${ISSUE_OR_TEXT}-{titre-simplifie}`
+       - Le titre est nettoyé (espaces -> tirets, caractères spéciaux supprimés, minuscules)
+     - Si c'est du texte :
+       - Génère un nom de branche : `feature/${ISSUE_OR_TEXT-simplifie}`
+       - Le texte est nettoyé (espaces -> tirets, caractères spéciaux supprimés, minuscules)
+   - Si pas de `ISSUE_OR_TEXT`, demande le nom de branche à l'utilisateur
+
+6. **Vérifier que la nouvelle branche n'existe pas déjà**
+   - `git branch --list "$NEW_BRANCH"`
+   - Si existe déjà → ARRÊTER avec erreur
+
+7. **Créer et checkout la nouvelle branche**
+   - `git checkout -b $NEW_BRANCH`
+   - La branche est créée depuis SOURCE_BRANCH (car on est dessus)
+
+8. **NE PAS configurer de tracking automatiquement**
+   - ❌ **INTERDIT** : `git branch --set-upstream-to=origin/$SOURCE_BRANCH $NEW_BRANCH`
+   - ✅ Le tracking sera configuré automatiquement lors du premier push avec `-u`
+   - ✅ Lors du push : `git push -u origin $NEW_BRANCH`
+   - **RAISON** : Configurer le tracking vers SOURCE_BRANCH pousse les commits sur la branche parente au lieu de créer une nouvelle branche distante
+
+## Expertise
+Conventions de nommage des branches :
+- `feature/nom-descriptif` : Nouvelles fonctionnalités
+- `fix/nom-bug` : Corrections de bugs
+- `issue/123-nom-descriptif` : Basé sur une issue GitHub
+- Utilise des tirets, pas d'espaces ni caractères spéciaux
+
+## Template
+```bash
+# Exemple d'usage avec numéro d'issue :
+/git:branch main 42
+
+# Résultat attendu :
+# - Récupère l'issue #42
+# - Titre: "Add user authentication system"
+# - Crée la branche: issue/42-add-user-authentication-system
+# - Checkout vers cette branche
+
+# Exemple d'usage avec texte :
+/git:branch main "Add login form"
+
+# Résultat attendu :
+# - Crée la branche: feature/add-login-form
+# - Checkout vers cette branche
+```
+
+## Examples
+```bash
+# Créer une branche depuis main avec issue GitHub
+/git:branch main 123
+
+# Créer une branche depuis main avec texte descriptif
+/git:branch main "user authentication"
+
+# Créer une branche depuis develop sans argument supplémentaire
+/git:branch develop
+
+# Créer une branche depuis une branche existante avec issue
+/git:branch feature/api-base 456
+
+# Créer une branche fix depuis main avec texte
+/git:branch main "fix login bug"
+```
+
+## Report
+- Nom de la branche créée
+- Branche source utilisée
+- Issue associée (si applicable)
+- Statut du checkout
+- Note : Le tracking remote sera configuré lors du premier push avec `git push -u origin $NEW_BRANCH`
+
+## Validation
+- ✅ `SOURCE_BRANCH` doit exister localement
+- ✅ `SOURCE_BRANCH` est obligatoire
+- ✅ **CHECKOUT vers SOURCE_BRANCH AVANT création** (CRITIQUE)
+- ✅ **PULL pour mettre à jour SOURCE_BRANCH** (CRITIQUE)
+- ✅ La nouvelle branche ne doit pas déjà exister
+- ✅ Si `ISSUE_OR_TEXT` est un numéro, l'issue doit exister sur GitHub
+- ✅ Le nom généré respecte les conventions de nommage
+- ✅ Détection automatique entre numéro d'issue et texte descriptif
+
+## Pourquoi checkout + pull vers SOURCE_BRANCH d'abord ?
+
+**Problème 1 évité** :
+- Si on est sur `feature/A` et on crée `feature/B` depuis `main`
+- Sans checkout vers `main` d'abord, la branche est créée depuis `feature/A`
+- Les commits de `feature/A` se retrouvent sur `feature/B`
+- Résultat : impossible de créer une PR propre
+
+**Problème 2 évité** :
+- Si `main` locale est en retard sur `origin/main`
+- Sans pull, on crée depuis un point obsolète
+- Résultat : commits manquants, conflits, PR avec historique incorrect
+
+**Solution** :
+1. TOUJOURS faire `git checkout $SOURCE_BRANCH`
+2. TOUJOURS faire `git pull origin $SOURCE_BRANCH`
+3. PUIS créer avec `git checkout -b $NEW_BRANCH`
--- a/commands/commit.md
+++ b/commands/commit.md
@@ -0,0 +1,161 @@
+---
+model: claude-sonnet-4-5-20250929
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git diff:*), Bash(git log:*), Bash(git push:*)
+argument-hint: [message] | --no-verify | --push
+description: Créer des commits bien formatés avec format conventional et emoji
+---
+
+# Commit Git Intelligent
+
+Créer un commit bien formaté : $ARGUMENTS
+
+## Ce Que Fait Cette Commande
+
+1. Sauf si spécifié avec --no-verify, exécute automatiquement les vérifications pre-commit :
+    - make qa pour assurer la qualité du code
+2. Vérifie quels fichiers sont stagés avec git status
+3. Si 0 fichiers sont stagés, ajoute automatiquement tous les fichiers modifiés et nouveaux avec git add
+4. Effectue un git diff pour comprendre les changements à commiter
+5. Analyse le diff pour déterminer si plusieurs changements logiques distincts sont présents
+6. Si plusieurs changements distincts sont détectés, suggère de diviser le commit en plusieurs commits plus petits
+7. Pour chaque commit (ou le commit unique si pas de division), crée un message de commit utilisant le format conventional avec emoji
+8. Si l'option --push est spécifiée, pousse automatiquement le(s) commit(s) vers le remote avec git push
+
+## Bonnes Pratiques pour les Commits
+
+- **Vérifier avant de commiter** : S'assurer que le code est linté, se build correctement, et que la documentation est à jour
+- **Commits atomiques** : Chaque commit doit contenir des changements liés qui servent un seul objectif
+- **Diviser les gros changements** : Si les changements touchent plusieurs préoccupations, les diviser en commits séparés
+- **Format conventional commit** : Utiliser le format <type>: <description> où type est un de :
+    - feat: Une nouvelle fonctionnalité
+    - fix: Une correction de bug
+    - docs: Changements de documentation
+    - style: Changements de style de code (formatage, etc)
+    - refactor: Changements de code qui ne corrigent pas de bugs ni n'ajoutent de fonctionnalités
+    - perf: Améliorations de performance
+    - test: Ajout ou correction de tests
+    - chore: Changements du processus de build, outils, etc.
+- **Présent, mode impératif** : Écrire les messages de commit comme des commandes (ex. "ajouter fonctionnalité" pas "ajouté fonctionnalité")
+- **Première ligne concise** : Garder la première ligne sous 72 caractères
+- **Emoji** : Chaque type de commit est associé à un emoji approprié :
+    - ✨ feat: Nouvelle fonctionnalité
+    - 🐛 fix: Correction de bug
+    - 📝 docs: Documentation
+    - 💄 style: Formatage/style
+    - ♻️ refactor: Refactorisation de code
+    - ⚡️ perf: Améliorations de performance
+    - ✅ test: Tests
+    - 🔧 chore: Outils, configuration
+    - 🚀 ci: Améliorations CI/CD
+    - 🗑️ revert: Annulation de changements
+    - 🧪 test: Ajouter un test qui échoue
+    - 🚨 fix: Corriger les warnings compilateur/linter
+    - 🔒️ fix: Corriger les problèmes de sécurité
+    - 👥 chore: Ajouter ou mettre à jour les contributeurs
+    - 🚚 refactor: Déplacer ou renommer des ressources
+    - 🏗️ refactor: Faire des changements architecturaux
+    - 🔀 chore: Fusionner des branches
+    - 📦️ chore: Ajouter ou mettre à jour les fichiers compilés ou packages
+    - ➕ chore: Ajouter une dépendance
+    - ➖ chore: Supprimer une dépendance
+    - 🌱 chore: Ajouter ou mettre à jour les fichiers de seed
+    - 🧑‍💻 chore: Améliorer l'expérience développeur
+    - 🧵 feat: Ajouter ou mettre à jour le code lié au multithreading ou à la concurrence
+    - 🔍️ feat: Améliorer le SEO
+    - 🏷️ feat: Ajouter ou mettre à jour les types
+    - 💬 feat: Ajouter ou mettre à jour le texte et les littéraux
+    - 🌐 feat: Internationalisation et localisation
+    - 👔 feat: Ajouter ou mettre à jour la logique métier
+    - 📱 feat: Travailler sur le design responsive
+    - 🚸 feat: Améliorer l'expérience utilisateur / utilisabilité
+    - 🩹 fix: Correction simple pour un problème non-critique
+    - 🥅 fix: Intercepter les erreurs
+    - 👽️ fix: Mettre à jour le code suite aux changements d'API externe
+    - 🔥 fix: Supprimer du code ou des fichiers
+    - 🎨 style: Améliorer la structure/format du code
+    - 🚑️ fix: Hotfix critique
+    - 🎉 chore: Commencer un projet
+    - 🔖 chore: Tags de release/version
+    - 🚧 wip: Travail en cours
+    - 💚 fix: Corriger le build CI
+    - 📌 chore: Épingler les dépendances à des versions spécifiques
+    - 👷 ci: Ajouter ou mettre à jour le système de build CI
+    - 📈 feat: Ajouter ou mettre à jour le code d'analytics ou de tracking
+    - ✏️ fix: Corriger les fautes de frappe
+    - ⏪️ revert: Annuler les changements
+    - 📄 chore: Ajouter ou mettre à jour la licence
+    - 💥 feat: Introduire des changements cassants
+    - 🍱 assets: Ajouter ou mettre à jour les assets
+    - ♿️ feat: Améliorer l'accessibilité
+    - 💡 docs: Ajouter ou mettre à jour les commentaires dans le code source
+    - 🗃️ db: Effectuer des changements liés à la base de données
+    - 🔊 feat: Ajouter ou mettre à jour les logs
+    - 🔇 fix: Supprimer les logs
+    - 🤡 test: Mocker des choses
+    - 🥚 feat: Ajouter ou mettre à jour un easter egg
+    - 🙈 chore: Ajouter ou mettre à jour le fichier .gitignore
+    - 📸 test: Ajouter ou mettre à jour les snapshots
+    - ⚗️ experiment: Effectuer des expériences
+    - 🚩 feat: Ajouter, mettre à jour, ou supprimer les feature flags
+    - 💫 ui: Ajouter ou mettre à jour les animations et transitions
+    - ⚰️ refactor: Supprimer le code mort
+    - 🦺 feat: Ajouter ou mettre à jour le code lié à la validation
+    - ✈️ feat: Améliorer le support hors ligne
+
+## Directives pour Diviser les Commits
+
+Lors de l'analyse du diff, considérer diviser les commits selon ces critères :
+
+1. **Préoccupations différentes** : Changements dans des parties non-liées du codebase
+2. **Types de changements différents** : Mélange de fonctionnalités, corrections, refactorisation, etc.
+3. **Patterns de fichiers** : Changements dans différents types de fichiers (ex. code source vs documentation)
+4. **Groupement logique** : Changements qui seraient plus faciles à comprendre ou réviser séparément
+5. **Taille** : Changements très larges qui seraient plus clairs s'ils étaient décomposés
+
+## Exemples
+
+Bons messages de commit :
+- ✨ feat: ajouter système d'authentification utilisateur
+- 🐛 fix: résoudre fuite mémoire dans le processus de rendu
+- 📝 docs: mettre à jour documentation API avec nouveaux endpoints
+- ♻️ refactor: simplifier la logique de gestion d'erreurs dans le parser
+- 🚨 fix: résoudre warnings linter dans les fichiers de composants
+- 🧑‍💻 chore: améliorer processus de setup des outils développeur
+- 👔 feat: implémenter logique métier pour validation de transaction
+- 🩹 fix: corriger incohérence de style mineure dans le header
+- 🚑️ fix: patcher vulnérabilité de sécurité critique dans le flux d'auth
+- 🎨 style: réorganiser structure des composants pour meilleure lisibilité
+- 🔥 fix: supprimer code legacy déprécié
+- 🦺 feat: ajouter validation d'entrée pour formulaire d'inscription utilisateur
+- 💚 fix: résoudre tests CI pipeline qui échouent
+- 📈 feat: implémenter tracking analytics pour engagement utilisateur
+- 🔒️ fix: renforcer exigences de mot de passe d'authentification
+- ♿️ feat: améliorer accessibilité des formulaires pour lecteurs d'écran
+
+Exemple de division de commits :
+- Premier commit : ✨ feat: ajouter définitions de types pour nouvelle version solc
+- Deuxième commit : 📝 docs: mettre à jour documentation pour nouvelles versions solc
+- Troisième commit : 🔧 chore: mettre à jour dépendances package.json
+- Quatrième commit : 🏷️ feat: ajouter définitions de types pour nouveaux endpoints API
+- Cinquième commit : 🧵 feat: améliorer gestion de concurrence dans worker threads
+- Sixième commit : 🚨 fix: résoudre problèmes de linting dans nouveau code
+- Septième commit : ✅ test: ajouter tests unitaires pour fonctionnalités nouvelle version solc
+- Huitième commit : 🔒️ fix: mettre à jour dépendances avec vulnérabilités de sécurité
+
+## Options de Commande
+
+- --no-verify: Ignorer l'exécution des vérifications pre-commit (qa)
+- --push: Pousser automatiquement le(s) commit(s) vers le remote après création
+
+## Notes Importantes
+
+- Par défaut, les vérifications pre-commit (qa) s'exécuteront pour assurer la qualité du code
+- Si ces vérifications échouent, il vous sera demandé si vous voulez procéder au commit quand même ou corriger les problèmes d'abord
+- Si des fichiers spécifiques sont déjà stagés, la commande ne commitera que ces fichiers
+- Si aucun fichier n'est stagé, elle stagera automatiquement tous les fichiers modifiés et nouveaux
+- Le message de commit sera construit basé sur les changements détectés
+- Avant de commiter, la commande révisera le diff pour identifier si plusieurs commits seraient plus appropriés
+- Si elle suggère plusieurs commits, elle vous aidera à stager et commiter les changements séparément
+- Révise toujours le diff du commit pour s'assurer que le message correspond aux changements
+- Avec --push, le commit sera automatiquement poussé vers le remote après création
+- Les options peuvent être combinées : /git:commit --no-verify --push
--- a/commands/conflit.md
+++ b/commands/conflit.md
@@ -0,0 +1,303 @@
+---
+model: claude-sonnet-4-5-20250929
+allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git merge:*), Bash(git rebase:*), Bash(git checkout:*), Bash(git add:*), Read, Edit
+argument-hint: <branche-destination>
+description: Analyse les conflits git et propose à l'utilisateur une résolution pas à pas avec validation de chaque étape.
+---
+
+# Résolution Interactive de Conflits Git
+
+Résoudre les conflits git de manière interactive : $ARGUMENTS
+
+## Purpose
+Analyser les conflits git et guider l'utilisateur dans une résolution pas à pas, fichier par fichier, avec validation à chaque étape.
+
+## Variables
+- DESTINATION_BRANCH: $1 (branche de destination pour le merge/rebase)
+- CURRENT_BRANCH: !`git branch --show-current`
+- CONFLICTED_FILES: Liste des fichiers en conflit
+- RESOLUTION_MODE: merge ou rebase (détecté automatiquement)
+
+## État Actuel du Repository
+
+- Branche actuelle : !`git branch --show-current`
+- Status Git : !`git status --porcelain`
+- Conflits détectés : !`git diff --name-only --diff-filter=U`
+- Commits divergents : !`git log --oneline HEAD...$DESTINATION_BRANCH --max-count=5`
+
+## Ce Que Fait Cette Commande
+
+1. Détecte s'il y a un merge/rebase en cours ou si on doit l'initier
+2. Identifie tous les fichiers en conflit
+3. Pour chaque fichier en conflit :
+   - Affiche le contexte du conflit
+   - Montre les différences entre les versions
+   - Propose 3 stratégies de résolution
+   - Demande validation avant d'appliquer
+4. Vérifie que tous les conflits sont résolus
+5. Finalise le merge/rebase
+
+## Workflow
+
+### 1. Validation initiale
+
+**Vérifier DESTINATION_BRANCH obligatoire :**
+- Si `DESTINATION_BRANCH` n'est pas fourni → ARRÊTER et demander à l'utilisateur
+
+**Vérifier que DESTINATION_BRANCH existe :**
+- `git branch --list "$DESTINATION_BRANCH"` (locale)
+- `git branch -r --list "origin/$DESTINATION_BRANCH"` (remote)
+- Si n'existe pas → ARRÊTER avec erreur
+
+**Vérifier l'état du repository :**
+- `git status` pour détecter :
+  - Merge en cours (fichiers "both modified")
+  - Rebase en cours (`.git/rebase-merge/` ou `.git/rebase-apply/`)
+  - Conflits existants
+
+### 2. Initier l'opération si nécessaire
+
+**Si aucun merge/rebase en cours :**
+- Demander à l'utilisateur : "Voulez-vous merger ou rebaser $CURRENT_BRANCH sur $DESTINATION_BRANCH ?"
+- Options :
+  1. Merge : `git merge $DESTINATION_BRANCH`
+  2. Rebase : `git rebase $DESTINATION_BRANCH`
+  3. Annuler
+- Exécuter l'opération choisie
+
+**Si l'opération échoue avec conflits :**
+- Continuer avec l'analyse des conflits
+
+### 3. Analyse des conflits
+
+**Lister tous les fichiers en conflit :**
+```bash
+git diff --name-only --diff-filter=U
+```
+
+**Pour chaque fichier, collecter :**
+- Chemin complet du fichier
+- Nombre de sections en conflit
+- Lignes concernées
+- Contexte (fonction/classe/module)
+
+### 4. Résolution interactive par fichier
+
+**Pour chaque fichier en conflit :**
+
+**Étape A : Afficher le contexte**
+- Nom du fichier et chemin
+- Nombre de conflits dans ce fichier
+- `git diff $FICHIER` pour voir les marqueurs de conflit
+
+**Étape B : Analyser les versions**
+- Lire le fichier avec Read pour voir les marqueurs :
+  - `<<<<<<< HEAD` : version actuelle
+  - `=======` : séparateur
+  - `>>>>>>> $DESTINATION_BRANCH` : version à merger
+- Afficher les différences de manière claire
+
+**Étape C : Proposer 3 stratégies**
+
+1. **Garder la version actuelle (ours)**
+   - `git checkout --ours $FICHIER`
+   - Quand : notre version est correcte, l'autre est obsolète
+
+2. **Garder la version entrante (theirs)**
+   - `git checkout --theirs $FICHIER`
+   - Quand : leur version est correcte, la nôtre est obsolète
+
+3. **Résolution manuelle**
+   - Utiliser Edit pour fusionner manuellement
+   - Supprimer les marqueurs `<<<<<<<`, `=======`, `>>>>>>>`
+   - Combiner les changements pertinents des deux versions
+
+**Étape D : Demander confirmation**
+- Afficher un résumé de la stratégie choisie
+- Demander : "Voulez-vous appliquer cette résolution ? (oui/non/voir le diff)"
+- Si "voir le diff" : montrer le résultat avec `git diff --cached $FICHIER`
+
+**Étape E : Appliquer la résolution**
+- Exécuter la stratégie choisie
+- Marquer le fichier comme résolu : `git add $FICHIER`
+- Confirmer : "✅ Conflit résolu dans $FICHIER"
+
+### 5. Vérification finale
+
+**Après avoir résolu tous les fichiers :**
+```bash
+git status
+```
+- Vérifier qu'il n'y a plus de fichiers "both modified"
+- Vérifier que tous les fichiers conflictuels sont stagés
+
+**Demander confirmation finale :**
+- "Tous les conflits sont résolus. Voulez-vous finaliser ?"
+- Options :
+  1. Oui, finaliser
+  2. Non, réviser les changements
+  3. Annuler tout (abort)
+
+### 6. Finalisation
+
+**Si merge :**
+```bash
+git commit --no-edit
+# ou si l'utilisateur veut personnaliser :
+git commit -m "Merge branch '$DESTINATION_BRANCH' into $CURRENT_BRANCH"
+```
+
+**Si rebase :**
+```bash
+git rebase --continue
+```
+
+**Si annulation demandée :**
+```bash
+git merge --abort   # ou
+git rebase --abort
+```
+
+## Stratégies de Résolution Détaillées
+
+### Stratégie 1 : Garder la version actuelle (ours)
+- Utilisation : Quand notre implémentation est plus récente/correcte
+- Commande : `git checkout --ours $FICHIER && git add $FICHIER`
+- Attention : Perte des changements de l'autre branche
+
+### Stratégie 2 : Garder la version entrante (theirs)
+- Utilisation : Quand la version à merger est plus récente/correcte
+- Commande : `git checkout --theirs $FICHIER && git add $FICHIER`
+- Attention : Perte de nos changements
+
+### Stratégie 3 : Résolution manuelle intelligente
+- Utilisation : Quand les deux versions contiennent des changements valides
+- Processus :
+  1. Lire le fichier avec Read
+  2. Identifier les sections en conflit
+  3. Analyser la logique de chaque version
+  4. Utiliser Edit pour fusionner :
+     - Garder les imports/dépendances des deux côtés
+     - Fusionner la logique métier intelligemment
+     - Supprimer tous les marqueurs de conflit
+  5. Vérifier la syntaxe du résultat
+  6. `git add $FICHIER`
+
+## Examples
+
+### Exemple 1 : Merge avec conflits
+```bash
+# Situation : on est sur feature/auth, on veut merger main
+/git:conflit main
+
+# Claude détecte : pas de merge en cours
+# Claude demande : "Voulez-vous merger main dans feature/auth ?"
+# Utilisateur : "oui, merge"
+# Claude exécute : git merge main
+# Conflits détectés dans : src/auth.php, config/app.php
+# Claude guide la résolution fichier par fichier
+```
+
+### Exemple 2 : Rebase en cours avec conflits
+```bash
+# Situation : rebase en cours, 3 fichiers en conflit
+/git:conflit develop
+
+# Claude détecte : rebase en cours sur develop
+# Claude liste : file1.php, file2.js, file3.md
+# Claude résout interactivement chaque fichier
+# Claude finalise : git rebase --continue
+```
+
+### Exemple 3 : Résolution manuelle complexe
+```bash
+/git:conflit main
+
+# Conflit dans src/payment.php :
+# HEAD : ajout méthode processRefund()
+# main : ajout méthode processChargeback()
+# Stratégie : Résolution manuelle
+# Claude fusionne les deux méthodes
+# Validation : utilisateur confirme
+```
+
+## Report Format
+
+```markdown
+# Rapport de Résolution de Conflits
+
+## Configuration
+- Branche actuelle : $CURRENT_BRANCH
+- Branche destination : $DESTINATION_BRANCH
+- Type d'opération : merge/rebase
+
+## Conflits Détectés
+- Nombre total de fichiers : X
+- Fichiers résolus : Y
+- Fichiers restants : Z
+
+## Résolutions Appliquées
+
+### Fichier : src/auth.php
+- Stratégie : Résolution manuelle
+- Raison : Fusion de deux implémentations valides
+- Lignes modifiées : 42-58
+
+### Fichier : config/app.php
+- Stratégie : Garder version actuelle (ours)
+- Raison : Configuration locale spécifique
+
+## Statut Final
+✅ Tous les conflits résolus
+✅ Merge/rebase finalisé avec succès
+```
+
+## Best Practices
+
+### Avant de commencer
+- ✅ S'assurer que le working directory est propre
+- ✅ Avoir une sauvegarde (commit ou stash)
+- ✅ Comprendre les changements des deux branches
+
+### Pendant la résolution
+- ✅ Résoudre un fichier à la fois
+- ✅ Tester la syntaxe après chaque résolution manuelle
+- ✅ Ne jamais garder les marqueurs de conflit (<<<<, ====, >>>>)
+- ✅ Valider que la logique est cohérente
+- ✅ En cas de doute, demander à l'utilisateur
+
+### Après la résolution
+- ✅ Vérifier que le code compile/s'exécute
+- ✅ Lancer les tests si disponibles
+- ✅ Réviser le diff final avant commit
+
+## Messages d'Erreur et Solutions
+
+### "error: you need to resolve your current index first"
+- Cause : Conflits non résolus
+- Solution : Continuer la résolution ou faire `git merge --abort`
+
+### "no changes added to commit"
+- Cause : Fichiers résolus mais non stagés
+- Solution : `git add $FICHIER` après chaque résolution
+
+### "conflict (content): Merge conflict in X"
+- Cause : Changements incompatibles dans le même fichier
+- Solution : Résoudre avec une des 3 stratégies
+
+## Validation
+
+- ✅ DESTINATION_BRANCH doit exister (locale ou remote)
+- ✅ Tous les fichiers en conflit doivent être traités
+- ✅ Aucun marqueur de conflit ne doit rester dans les fichiers
+- ✅ Tous les fichiers résolus doivent être stagés
+- ✅ L'utilisateur doit valider avant chaque résolution
+- ✅ L'utilisateur doit confirmer avant la finalisation
+
+## Notes Importantes
+
+- La commande est 100% interactive : chaque action nécessite validation
+- L'utilisateur garde le contrôle total du processus
+- Possibilité d'annuler à tout moment avec merge/rebase --abort
+- Les résolutions manuelles utilisent Edit pour garantir la qualité
+- Un rapport détaillé est généré à la fin
--- a/commands/pr.md
+++ b/commands/pr.md
@@ -0,0 +1,6 @@
+---
+description: Crée une Pull Request optimisée avec workflow structuré
+argument-hint: [branch-base, milestone, project, --delete, --no-review]
+---
+
+You must use the Skill tool to invoke the "git-pr" skill with the following arguments.
--- a/commands/release-notes.md
+++ b/commands/release-notes.md
@@ -0,0 +1,6 @@
+---
+description: Génère des notes de release HTML orientées utilisateurs finaux
+argument-hint: "<branche-source> <branche-cible> [nom-release]"
+---
+
+You must use the Skill tool to invoke the "git:release-notes" skill.
--- a/commands/release-report.md
+++ b/commands/release-report.md
@@ -0,0 +1,270 @@
+---
+name: git:release-report
+description: Génère un rapport HTML d'analyse d'impact entre deux branches
+argument-hint: [branch-source, branche-cible, nom-release]
+arguments:
+  - name: branche-source
+    description: Branche source à analyser (ex release/v27.0.0)
+    required: true
+  - name: branche-cible
+    description: Branche de référence (ex main ou develop)
+    required: true
+  - name: nom-release
+    description: Nom de la release pour le fichier (optionnel)
+    required: false
+---
+
+# Générer rapport d'analyse de release
+
+Génère un rapport HTML détaillé comparant deux branches pour analyser l'impact d'une release.
+
+## Usage
+
+```bash
+/git:release-report <branche-source> <branche-cible> [nom-release]
+```
+
+**Exemples :**
+- `/git:release-report release/v27.0.0 main`
+- `/git:release-report release/v27.0.0 develop v27.0.0`
+- `/git:release-report feature/new-module main "Module XYZ"`
+
+## Description
+
+Cette commande génère un rapport HTML orienté Product Owner qui analyse :
+
+1. **Statistiques globales** : fichiers modifiés, lignes ajoutées/supprimées, commits
+2. **Répartition par type de fichier** : PHP, Twig, JS, etc.
+3. **Fonctionnalités principales** : extraction depuis les commits
+4. **Impact métier** : par domaine fonctionnel
+5. **Qualité & maintenabilité** : évolution du code
+
+Le rapport est généré dans `REPORT_PATH/impact_<nom-release>.html`
+
+## Variables
+
+REPORT_PATH: `.claude/reports`
+
+Variables à extraire des arguments :
+
+- `$BRANCH_SOURCE` : Branche source à analyser (ex: release/v27.0.0)
+- `$BRANCH_TARGET` : Branche de référence (ex: main ou develop)
+- `$RELEASE_NAME` : Nom de la release pour le fichier (ex: v27.0.0)
+
+Si `$RELEASE_NAME` n'est pas fourni, utiliser le nom de `$BRANCH_SOURCE` en retirant le préfixe "release/"
+
+## Workflow
+
+### 0. Vérification des arguments obligatoires
+
+**AVANT TOUTE EXÉCUTION**, vérifier que les arguments obligatoires sont fournis :
+
+1. Si `$BRANCH_SOURCE` est manquant :
+   - Utiliser `AskUserQuestion` pour demander la branche source
+   - Question : "Quelle est la branche source à analyser ?"
+   - Proposer les branches récentes de type `release/*` ou `feature/*`
+
+2. Si `$BRANCH_TARGET` est manquant :
+   - Utiliser `AskUserQuestion` pour demander la branche cible
+   - Question : "Quelle est la branche de référence ?"
+   - Options suggérées : `main`, `develop`, `master`
+
+**Ne pas continuer** tant que les deux arguments obligatoires ne sont pas fournis.
+
+### 1. Validation des paramètres
+
+```bash
+# Vérifier que les branches existent
+git rev-parse --verify $BRANCH_SOURCE
+git rev-parse --verify $BRANCH_TARGET
+
+# Vérifier qu'il y a des différences
+DIFF_COUNT=$(git rev-list --count $BRANCH_TARGET..$BRANCH_SOURCE)
+if [ $DIFF_COUNT -eq 0 ]; then
+    echo "Aucune différence entre les branches"
+    exit 1
+fi
+```
+
+### 2. Collecte des statistiques git
+
+Exécuter les commandes suivantes en parallèle :
+
+```bash
+# Statistiques globales
+git diff --stat $BRANCH_TARGET..$BRANCH_SOURCE | tail -1
+
+# Nombre total de fichiers modifiés et détails lignes
+git diff --numstat $BRANCH_TARGET..$BRANCH_SOURCE | \
+  awk '{files++; added+=$1; deleted+=$2} END {print files, added, deleted}'
+
+# Répartition par type de fichier
+git diff --numstat $BRANCH_TARGET..$BRANCH_SOURCE | python3 -c "
+import sys
+from collections import defaultdict
+
+stats = defaultdict(lambda: {'count': 0, 'added': 0, 'deleted': 0})
+
+for line in sys.stdin:
+    parts = line.strip().split('\t')
+    if len(parts) < 3:
+        continue
+
+    added = int(parts[0]) if parts[0] != '-' else 0
+    deleted = int(parts[1]) if parts[1] != '-' else 0
+    path = parts[2]
+
+    ext = 'autre'
+    if path.endswith('.php'):
+        ext = 'php'
+    elif path.endswith('.twig'):
+        ext = 'twig'
+    elif path.endswith(('.yml', '.yaml')):
+        ext = 'yaml'
+    elif path.endswith('.js'):
+        ext = 'js'
+    elif path.endswith('.scss'):
+        ext = 'scss'
+    elif path.endswith('.md'):
+        ext = 'md'
+    elif path.endswith('.json'):
+        ext = 'json'
+    elif path.endswith('.sh'):
+        ext = 'sh'
+
+    stats[ext]['count'] += 1
+    stats[ext]['added'] += added
+    stats[ext]['deleted'] += deleted
+    stats[ext]['total'] = stats[ext]['added'] + stats[ext]['deleted']
+
+for ext in sorted(stats.items(), key=lambda x: x[1]['total'], reverse=True):
+    name = ext[0]
+    data = ext[1]
+    print(f'{name}|{data[\"count\"]}|{data[\"added\"]}|{data[\"deleted\"]}|{data[\"total\"]}')
+"
+
+# Types de modifications (A/M/D/R)
+git diff --name-status $BRANCH_TARGET..$BRANCH_SOURCE | cut -f1 | sort | uniq -c
+
+# Nombre de commits
+git rev-list --count $BRANCH_TARGET..$BRANCH_SOURCE
+
+# Total fichiers dans la branche cible
+git ls-tree -r $BRANCH_TARGET --name-only | wc -l
+
+# Top commits avec features/fixes
+git log $BRANCH_TARGET..$BRANCH_SOURCE --oneline --no-merges | \
+  grep -E "(feat|feature|✨|🚀|📝|🐛|fix|♻️|refactor)" | head -50
+```
+
+### 3. Analyse des domaines fonctionnels
+
+Analyser les commits pour identifier les domaines principaux impactés :
+
+- Grouper par préfixe de commit (AVENANT, DOSSIER, APF, etc.)
+- Identifier les patterns récurrents
+- Extraire les fonctionnalités majeures avec leur impact
+
+### 4. Génération du rapport HTML
+
+Utiliser le template suivant et remplir avec les données collectées :
+
+**Structure du rapport :**
+
+1. **Header** avec executive summary
+   - Nom de la release
+   - Résumé en 2-3 phrases
+   - Chiffres clés (% code modifié, commits, variation nette)
+
+2. **KPI Grid** (4 indicateurs visuels)
+   - % du code modifié
+   - Nombre de commits
+   - Variation nette (simplification/ajout)
+   - Domaine principal (ex: "70% focus AVENANTS")
+
+3. **Fonctionnalités principales** (cards avec impact)
+   - Impact Très élevé (rouge)
+   - Impact Élevé (orange)
+   - Impact Moyen (jaune)
+   - Impact Faible (vert)
+
+4. **Corrections majeures**
+   - Liste des bugs corrigés
+
+5. **Qualité & Maintenabilité**
+   - Code simplifié
+   - Documentation
+   - Refactoring
+   - Interface
+
+6. **Vue d'ensemble technique**
+   - Chart bars par type de fichier
+   - Métrique périmètre impacté
+
+7. **Impact business** (4 axes)
+   - Gestion administrative
+   - Communication
+   - Performance
+   - Sécurité
+
+**Style CSS :**
+- Gradient violet (#667eea → #764ba2)
+- Cards avec border-left coloré selon impact
+- Progress bars animées
+- KPI boxes avec fond dégradé
+- Design responsive
+
+### 5. Sauvegarde du fichier
+
+```bash
+OUTPUT_FILE="REPORT_PATH/impact_${RELEASE_NAME}.html"
+mkdir -p REPORT_PATH
+# Écrire le contenu HTML généré
+echo "Rapport généré : $OUTPUT_FILE"
+```
+
+## Format de sortie
+
+Le rapport doit être :
+
+- **Orienté Product Owner** : focus sur l'impact métier, pas les détails techniques
+- **Visuel** : KPI, charts, couleurs par niveau d'impact
+- **Actionnable** : lister les features, bugs corrigés, améliorations
+- **Comparable** : même structure pour toutes les releases
+
+## Règles importantes
+
+1. **NE PAS** utiliser de termes techniques obscurs
+2. **TOUJOURS** expliquer l'impact utilisateur
+3. **GROUPER** les changements par domaine fonctionnel
+4. **QUANTIFIER** l'impact (%, nombre, ratio)
+5. **PRIORISER** par impact métier (Très élevé → Faible)
+
+## Exemple d'exécution
+
+```bash
+$ /git:release-report release/v27.0.0 main
+
+Analyse de release/v27.0.0 vs main...
+
+✓ Collecte statistiques git
+✓ Analyse types de fichiers
+✓ Extraction fonctionnalités
+✓ Génération rapport HTML
+
+Rapport généré : REPORT_PATH/impact_v27.0.0.html
+
+Résumé :
+- 1 250 fichiers modifiés (17.5% du codebase)
+- 45 320 lignes ajoutées, 38 100 lignes supprimées
+- +7 220 lignes nettes (+10.2%)
+- 780 commits
+- Focus principal : NOTIFICATIONS (65%)
+```
+
+## Notes
+
+- Le rapport est auto-suffisant (HTML avec CSS inline)
+- Compatible tous navigateurs modernes
+- Peut être imprimé ou converti en PDF
+- Les couleurs suivent le design system du projet