mdma-cli 4.3.0 → 4.5.0

package/bin/init.js

@@ -9,6 +9,10 @@ const __dirname = dirname(fileURLToPath(import.meta.url));
 const PKG_ROOT = join(__dirname, '..');
 const TEMPLATES_SRC = join(PKG_ROOT, 'templates');
 const RULES_DEST = join(process.cwd(), '.claude', 'rules', 'mdma');
+const SKILLS_SRC = join(TEMPLATES_SRC, 'skills');
+const SKILLS_DEST = join(process.cwd(), '.claude', 'skills', 'mdma');
+const SUBAGENTS_SRC = join(TEMPLATES_SRC, 'subagents');
+const SUBAGENTS_DEST = join(process.cwd(), '.claude', 'subagents', 'mdma');
 
 const CORE_FILES = ['models.md', 'style.md', 'best-practices.md'];
 
@@ -60,6 +64,30 @@ function listOptions() {
   console.log('\nUsage: npx mdma-cli add [preset] or npx mdma-cli add --workflow=X --git=Y\n');
 }
 
+function copyDirRecursive(src, dest) {
+  if (!existsSync(src)) {
+    return 0;
+  }
+
+  mkdirSync(dest, { recursive: true });
+  let count = 0;
+
+  const entries = readdirSync(src, { withFileTypes: true });
+  for (const entry of entries) {
+    const srcPath = join(src, entry.name);
+    const destPath = join(dest, entry.name);
+
+    if (entry.isDirectory()) {
+      count += copyDirRecursive(srcPath, destPath);
+    } else if (entry.name.endsWith('.md')) {
+      copyFileSync(srcPath, destPath);
+      count++;
+    }
+  }
+
+  return count;
+}
+
 function updateGitExclude() {
   const excludePath = join(process.cwd(), '.git', 'info', 'exclude');
 
@@ -187,6 +215,20 @@ function add(args) {
   copyFileSync(gitFile, join(RULES_DEST, `git-${git}.md`));
   console.log(`  [ok] git-${git}.md`);
 
+  // Copy skills
+  rmSync(SKILLS_DEST, { recursive: true, force: true });
+  const skillsCount = copyDirRecursive(SKILLS_SRC, SKILLS_DEST);
+  if (skillsCount > 0) {
+    console.log(`  [ok] skills/ (${skillsCount} files)`);
+  }
+
+  // Copy subagents
+  rmSync(SUBAGENTS_DEST, { recursive: true, force: true });
+  const subagentsCount = copyDirRecursive(SUBAGENTS_SRC, SUBAGENTS_DEST);
+  if (subagentsCount > 0) {
+    console.log(`  [ok] subagents/ (${subagentsCount} files)`);
+  }
+
   // Update .git/info/exclude
   const excludeResult = updateGitExclude();
   if (excludeResult === true) {
@@ -208,7 +250,8 @@ function add(args) {
     console.log(`         Run manually: claude mcp add context7 --scope user -- npx -y @upstash/context7-mcp`);
   }
 
-  console.log(`\n5 file(s) installed to .claude/rules/mdma/\n`);
+  const totalFiles = CORE_FILES.length + 2 + skillsCount + subagentsCount; // core + workflow + git + skills + subagents
+  console.log(`\n${totalFiles} file(s) installed to .claude/\n`);
 }
 
 function main() {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "mdma-cli",
-  "version": "4.3.0",
+  "version": "4.5.0",
   "description": "Rules opinionated pour agents de code",
   "type": "module",
   "license": "MIT",
@@ -10,7 +10,7 @@
   },
   "author": "privaloops",
   "scripts": {
-    "test": "node bin/init.js add"
+    "test": "node tests/install.test.js"
   },
   "bin": {
     "mdma-cli": "bin/init.js"

package/templates/models.md

@@ -10,9 +10,21 @@ Utiliser le modèle approprié selon la complexité de la tâche pour optimiser
 | Exploration de code, recherche | `sonnet` | Bon équilibre |
 | Implémentation, review, architecture | `opus` | Raisonnement complexe |
 
-## Syntaxe
+## Application automatique
 
-Spécifier le modèle dans la demande si besoin :
+Les skills et subagents mdma appliquent cette logique automatiquement :
+
+| Skill/Subagent | Modèle | Raison |
+|----------------|--------|--------|
+| `/test` | `haiku` | Exécution de commandes |
+| `review-lint` | `haiku` | Exécution d'outils, pas d'analyse |
+| `review-bundle` | `haiku` | Lecture de métriques |
+| `review-security` | `sonnet` | Analyse des deps, patterns connus |
+| `review-best-practices` | `opus` | Raisonnement sur le code, contexte |
+
+## Tâches ad-hoc
+
+Pour les tâches hors skills, spécifier le modèle si besoin :
 - "Lance les tests avec haiku"
 - "Explore le code avec sonnet"
 

package/templates/skills/master-plan/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: master-plan
+description: Crée un plan de projet structuré (MASTER-PLAN.md) via questions itératives
+allowed-tools: Read, Glob, Grep, Bash, Write, AskUserQuestion
+model: opus
+---
+
+# Master Plan
+
+Génère un plan de projet complet et structuré via un processus itératif de questions/réponses.
+
+## Output
+
+Fichier `MASTER-PLAN.md` à la racine du projet.
+
+## Process
+
+### Phase 1 : Comprendre le projet
+
+Pose ces questions à l'utilisateur **une par une** (utilise AskUserQuestion avec réponses ouvertes) :
+
+#### Question 1 : Nature et contexte
+> "Décris le projet en quelques phrases : qu'est-ce que c'est, pour qui, dans quel contexte ?"
+
+#### Question 2 : Objectif principal
+> "Quel est l'objectif principal de ce projet ? Quel problème résout-il ?"
+
+#### Question 3 : Livrables prioritaires
+> "Quels sont les prochains livrables concrets que tu veux atteindre ?"
+
+#### Question 4 : Contraintes
+> "Y a-t-il des contraintes particulières ? (deadline, stack imposée, dépendances, etc.)"
+
+**Note** : Utilise des questions ouvertes. L'utilisateur répond librement. Si une réponse n'est pas claire, demande des précisions.
+
+### Phase 2 : Explorer le codebase (si existant)
+
+Si du code existe déjà :
+1. Analyse la structure des dossiers
+2. Identifie les technologies utilisées (package.json, Gemfile, go.mod, etc.)
+3. Compte les fichiers et lignes de code
+4. Identifie les dépendances principales
+5. Résume l'état actuel à l'utilisateur
+
+### Phase 3 : Proposer une structure de plan
+
+Avant de générer le fichier, propose la structure des phases à l'utilisateur :
+
+> "Voici les phases que je propose :
+> - Phase 1 : [nom] - [description courte]
+> - Phase 2 : [nom] - [description courte]
+> - ...
+>
+> Tu valides ? Tu veux ajouter/retirer/modifier des phases ?"
+
+Attends validation avant de générer.
+
+### Phase 4 : Générer le plan
+
+Structure du fichier `MASTER-PLAN.md` :
+
+```markdown
+# Plan de Projet - [Nom du projet]
+
+> **Projet** : [description courte]
+> **Contexte** : [contexte]
+> **Objectif** : [objectif principal]
+> **Date** : [date de création]
+
+---
+
+## Table des matières
+
+1. [Vue d'ensemble](#1-vue-densemble)
+2. [État actuel](#2-état-actuel)
+3. [Architecture cible](#3-architecture-cible)
+4. [Phases d'implémentation](#4-phases-dimplémentation)
+5. [Stratégie de tests](#5-stratégie-de-tests)
+6. [Critères d'acceptation](#6-critères-dacceptation)
+7. [Risques et mitigations](#7-risques-et-mitigations)
+8. [Conventions](#8-conventions)
+
+[... contenu basé sur les réponses de l'utilisateur ...]
+```
+
+### Phase 5 : Créer les issues (optionnel)
+
+Demande à l'utilisateur :
+> "Veux-tu que je crée les issues GitHub pour chaque phase ?"
+
+Si oui et que le projet utilise GitHub :
+1. Crée une issue pour chaque phase
+2. Ajoute les tâches et critères d'acceptation
+
+## Principes
+
+- **Questions ouvertes** : laisse l'utilisateur s'exprimer, ne pas imposer des choix
+- **Itératif** : plusieurs allers-retours, valider chaque étape
+- **Pas d'invention** : ne pas ajouter de features/phases non demandées
+- **STOP fréquents** : valider avant de générer, valider avant de créer les issues

package/templates/skills/review/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: review
+description: Analyse qualité du code avant les tests (best practices, sécurité, lint, bundle)
+allowed-tools: Bash, Read, Grep, Glob, Task
+---
+
+# Review
+
+Analyse qualité du code modifié via 4 subagents parallèles.
+
+## Contexte à récupérer
+
+```bash
+# Fichiers modifiés
+git diff --name-only HEAD~1 2>/dev/null || git diff --name-only --cached
+```
+
+## Détection du projet
+
+Avant de lancer les subagents, détecte le contexte :
+
+| Fichier | Type projet | Outils disponibles |
+|---------|-------------|-------------------|
+| `package.json` | Node.js | npm audit, eslint, prettier |
+| `requirements.txt` / `pyproject.toml` | Python | pip-audit, ruff, black |
+| `go.mod` | Go | govulncheck, golint |
+| `Gemfile` | Ruby | bundle audit, rubocop |
+| `Cargo.toml` | Rust | cargo audit, clippy |
+
+## Subagents à lancer
+
+Lance les subagents **en parallèle** avec `run_in_background: true` :
+
+1. **review-best-practices** (toujours)
+   - Modèle : opus
+   - Analyse : patterns, DRY, KISS, conventions
+
+2. **review-security** (si gestionnaire de deps détecté)
+   - Modèle : sonnet
+   - Analyse : nouvelles deps, vulnérabilités connues
+
+3. **review-lint** (si linter configuré)
+   - Modèle : haiku
+   - Analyse : erreurs lint, formatting
+
+4. **review-bundle** (si bundler détecté : webpack, vite, esbuild)
+   - Modèle : haiku
+   - Analyse : impact sur le bundle size
+
+## Agrégation
+
+Une fois tous les subagents terminés :
+
+1. Récupère les résultats via `TaskOutput`
+2. Agrège dans un rapport unifié :
+
+```markdown
+## Rapport Review
+
+### Best Practices
+[résultats review-best-practices]
+
+### Sécurité
+[résultats review-security ou "N/A - pas de gestionnaire de deps"]
+
+### Lint
+[résultats review-lint ou "N/A - pas de linter configuré"]
+
+### Bundle
+[résultats review-bundle ou "N/A - pas de bundler"]
+
+### Actions requises
+- [ ] Liste des corrections à faire
+```
+
+3. Si problèmes critiques détectés → **STOP** → demande correction avant de continuer

package/templates/skills/test/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: test
+description: Exécute les tests du projet (détection automatique du runner)
+allowed-tools: Bash, Read, Glob
+model: haiku
+---
+
+# Test
+
+Exécute les tests du projet avec détection automatique du runner.
+
+## Détection du runner
+
+| Fichier | Runner | Commande |
+|---------|--------|----------|
+| `package.json` | npm/yarn/pnpm | `npm test` ou script défini |
+| `pytest.ini` / `pyproject.toml` (pytest) | pytest | `pytest` |
+| `go.mod` | go test | `go test ./...` |
+| `Gemfile` | rspec/minitest | `bundle exec rspec` ou `bundle exec rake test` |
+| `Cargo.toml` | cargo | `cargo test` |
+| `Makefile` (avec target test) | make | `make test` |
+
+### Priorité
+
+1. Vérifie d'abord `CLAUDE.md` pour une commande explicite
+2. Sinon, détecte selon le tableau ci-dessus
+3. Si aucune détection → **STOP** → demande la commande à l'utilisateur
+
+## Exécution
+
+```
+1. Lance la commande de test
+2. Si FAIL :
+   - Identifie LE test qui échoue
+   - Corrige CE test uniquement
+   - Relance la suite complète
+   - Max 5 itérations
+3. Si toujours FAIL après 5 itérations → **STOP** → demande quoi faire
+4. Si PASS → rapport de succès
+```
+
+## Rapport
+
+```markdown
+## Rapport Tests
+
+- **Runner** : [runner détecté]
+- **Commande** : [commande exécutée]
+- **Résultat** : PASS / FAIL
+- **Itérations** : X/5
+
+### Détails
+[sortie des tests ou résumé]
+```
+
+## Notes
+
+- Ne modifie PAS le code métier pour faire passer les tests
+- Si un test échoue à cause d'un bug dans le code → signale-le, ne le masque pas
+- Les tests de snapshot/baseline sont gérés par `/visual-test`

package/templates/subagents/review-best-practices.md

@@ -0,0 +1,69 @@
+---
+name: review-best-practices
+description: Analyse les best practices du code (patterns, DRY, KISS, conventions)
+model: opus
+allowed-tools: Read, Grep, Glob
+---
+
+# Review Best Practices
+
+Analyse le code modifié pour vérifier le respect des best practices.
+
+## Fichiers à analyser
+
+Reçus en argument : liste des fichiers modifiés.
+
+## Critères d'analyse
+
+### 1. Patterns et conventions
+- Cohérence avec le style existant du projet
+- Nommage (variables, fonctions, classes)
+- Structure du code
+
+### 2. DRY (Don't Repeat Yourself)
+- Duplication de code
+- Logique répétée qui pourrait être factorisée
+- Copier-coller détectable
+
+### 3. KISS (Keep It Simple, Stupid)
+- Over-engineering
+- Abstractions prématurées
+- Complexité inutile
+
+### 4. YAGNI (You Ain't Gonna Need It)
+- Code mort ou inutilisé
+- Features non demandées
+- Configurations superflues
+
+### 5. Lisibilité
+- Fonctions trop longues (> 50 lignes)
+- Nesting excessif (> 3 niveaux)
+- Manque de clarté
+
+## Output
+
+```markdown
+## Best Practices Review
+
+### Score global : X/10
+
+### Problèmes détectés
+
+#### Critiques (bloquants)
+- [fichier:ligne] Description du problème
+
+#### Majeurs (à corriger)
+- [fichier:ligne] Description du problème
+
+#### Mineurs (suggestions)
+- [fichier:ligne] Description du problème
+
+### Points positifs
+- Liste des bonnes pratiques observées
+```
+
+## Notes
+
+- Compare avec les conventions du projet (CLAUDE.md, .editorconfig, etc.)
+- Ne suggère PAS de refactoring massif hors scope
+- Focus sur les fichiers modifiés uniquement

package/templates/subagents/review-bundle.md

@@ -0,0 +1,83 @@
+---
+name: review-bundle
+description: Analyse l'impact sur le bundle size (projets frontend)
+model: haiku
+allowed-tools: Bash, Read, Glob
+---
+
+# Review Bundle
+
+Analyse l'impact des modifications sur le bundle size.
+
+## Détection du bundler
+
+| Fichier | Bundler | Outil d'analyse |
+|---------|---------|-----------------|
+| `webpack.config.*` | Webpack | `webpack --profile --json` |
+| `vite.config.*` | Vite | `vite build --report` |
+| `esbuild.*` / script esbuild | esbuild | `esbuild --metafile` |
+| `rollup.config.*` | Rollup | `rollup --plugin visualizer` |
+| `next.config.*` | Next.js | `next build` (affiche les sizes) |
+| `nuxt.config.*` | Nuxt | `nuxt build --analyze` |
+
+## Vérifications
+
+### 1. Nouvelles dépendances
+
+Pour chaque nouvelle dépendance dans package.json :
+- Taille du package (bundlephobia.com)
+- Tree-shaking supporté ?
+- Alternatives plus légères ?
+
+### 2. Build analysis
+
+Si possible, compare avant/après :
+```bash
+# Avant (main branch)
+git stash && npm run build && ls -la dist/
+
+# Après (current)
+git stash pop && npm run build && ls -la dist/
+```
+
+### 3. Imports
+
+Vérifie les imports problématiques :
+- Import de librairie entière vs named imports
+- Dynamic imports manquants pour le code splitting
+- Dépendances dupliquées
+
+## Output
+
+```markdown
+## Bundle Review
+
+### Bundler détecté
+[bundler] avec config [fichier]
+
+### Nouvelles dépendances
+
+| Package | Taille (min+gzip) | Tree-shakable | Impact estimé |
+|---------|-------------------|---------------|---------------|
+| lodash | 71kb | Non | CRITIQUE |
+| date-fns | 13kb | Oui | OK |
+
+### Analyse des imports
+
+#### Problèmes détectés
+- [fichier:ligne] Import complet de [lib] - utiliser named imports
+
+#### Suggestions
+- Lazy load [composant] pour réduire le bundle initial
+
+### Impact estimé
+- Bundle avant : ~Xkb
+- Bundle après : ~Xkb
+- Différence : +X% / -X%
+```
+
+## Notes
+
+- Si pas de bundler détecté → "N/A - pas de bundler frontend"
+- Ne bloque que si augmentation > 10% sans justification
+- Suggère des alternatives mais ne les impose pas

package/templates/subagents/review-lint.md

@@ -0,0 +1,69 @@
+---
+name: review-lint
+description: Vérifie le lint et le formatting du code
+model: haiku
+allowed-tools: Bash, Read, Glob
+---
+
+# Review Lint
+
+Exécute les linters et formatters configurés sur les fichiers modifiés.
+
+## Détection des outils
+
+| Fichier config | Outil | Commande |
+|----------------|-------|----------|
+| `.eslintrc*` / `eslint.config.*` | ESLint | `npx eslint [files]` |
+| `.prettierrc*` | Prettier | `npx prettier --check [files]` |
+| `pyproject.toml` (ruff) | Ruff | `ruff check [files]` |
+| `.flake8` / `setup.cfg` | Flake8 | `flake8 [files]` |
+| `.golangci.yml` | golangci-lint | `golangci-lint run [files]` |
+| `.rubocop.yml` | RuboCop | `rubocop [files]` |
+| `rustfmt.toml` | rustfmt | `cargo fmt --check` |
+| `.editorconfig` | editorconfig-checker | `editorconfig-checker [files]` |
+
+## Workflow
+
+```
+1. Identifie les linters configurés dans le projet
+2. Exécute chaque linter sur les fichiers modifiés
+3. Collecte les erreurs et warnings
+4. Catégorise par sévérité
+```
+
+## Output
+
+```markdown
+## Lint Review
+
+### Outils détectés
+- ESLint : oui/non
+- Prettier : oui/non
+- [autres]
+
+### Résultats
+
+#### Erreurs (bloquantes)
+- [fichier:ligne] [règle] Message
+
+#### Warnings
+- [fichier:ligne] [règle] Message
+
+### Commandes de fix automatique
+```bash
+npx eslint --fix [files]
+npx prettier --write [files]
+```
+
+### Résumé
+- Erreurs : X
+- Warnings : X
+- Fichiers analysés : X
+```
+
+## Notes
+
+- Si aucun linter configuré → signale "Aucun linter détecté"
+- Les erreurs de lint sont bloquantes
+- Les warnings sont informatifs
+- Propose les commandes de fix quand disponibles

package/templates/subagents/review-security.md

@@ -0,0 +1,89 @@
+---
+name: review-security
+description: Audit de sécurité des dépendances et du code
+model: sonnet
+allowed-tools: Bash, Read, Grep, Glob
+---
+
+# Review Security
+
+Analyse la sécurité des dépendances nouvellement ajoutées et du code.
+
+## 1. Audit des dépendances
+
+### Détection des nouvelles deps
+
+```bash
+# Node.js
+git diff HEAD~1 -- package.json | grep "^\+" | grep -v "^\+\+\+"
+
+# Python
+git diff HEAD~1 -- requirements.txt pyproject.toml | grep "^\+"
+
+# Go
+git diff HEAD~1 -- go.mod | grep "^\+"
+
+# Ruby
+git diff HEAD~1 -- Gemfile | grep "^\+"
+```
+
+### Outils d'audit
+
+| Écosystème | Commande |
+|------------|----------|
+| Node.js | `npm audit` |
+| Python | `pip-audit` ou `safety check` |
+| Go | `govulncheck ./...` |
+| Ruby | `bundle audit check` |
+| Rust | `cargo audit` |
+
+### Vérifications manuelles
+
+Pour chaque nouvelle dépendance :
+1. **Popularité** : nombre de téléchargements, stars GitHub
+2. **Maintenance** : dernier commit, issues ouvertes
+3. **Sécurité** : CVE connues, historique de vulnérabilités
+
+## 2. Analyse du code
+
+### Patterns à détecter
+
+- Injection SQL : concaténation de strings dans les requêtes
+- XSS : output non échappé
+- Command injection : exec/spawn avec input utilisateur
+- Path traversal : manipulation de chemins fichiers
+- Secrets hardcodés : API keys, passwords dans le code
+- Permissions trop larges : chmod 777, accès root
+
+## Output
+
+```markdown
+## Security Review
+
+### Dépendances
+
+#### Nouvelles dépendances détectées
+| Package | Version | Vulnérabilités | Popularité |
+|---------|---------|----------------|------------|
+| xxx | 1.0.0 | 0 | OK |
+
+#### Audit automatique
+[sortie de npm audit / pip-audit / etc.]
+
+### Code
+
+#### Vulnérabilités potentielles
+- [fichier:ligne] [CRITIQUE/MAJEUR/MINEUR] Description
+
+#### Secrets détectés
+- [fichier:ligne] Type de secret potentiel
+
+### Recommandations
+- Liste des actions correctives
+```
+
+## Notes
+
+- Les vulnérabilités critiques sont **bloquantes**
+- Signale les faux positifs possibles
+- Ne bloque pas sur les vulnérabilités low/info des deps transitives

package/templates/workflow-default.md

@@ -24,25 +24,14 @@
 - Petits commits logiques (conventions dans `git.md`)
 - **STOP** → montre les modifications, attend validation
 
-### 3. Test
-- Lance les tests (commande dans `CLAUDE.md`)
-- Si fail → arrête et fixe CE test uniquement
-- Si le test passe → relance la suite complète
-- Max 5 itérations
-- Si toujours fail → **STOP** → demande quoi faire
-
-#### 3.1 Tests visuels (obligatoire si applicable)
-- **Vérifie** si `.claude/rules/visual-test.md` existe
-- Si oui → exécute `/screenshot` et compare `current/` vs `baseline/`
-- Différence intentionnelle → mettre à jour `baseline/`
-- Régression détectée → **STOP** → corriger avant de continuer
-
-- Si tous les tests passent → **STOP** → attend validation
-
-### 4. Review
-- Review ton propre code
-- Vérifie : sécurité, performance, lisibilité
-- Propose des améliorations si pertinent
+### 3. Review
+- Exécute `/review`
+- Corrige les problèmes critiques détectés
+- **STOP** → attend validation avant de passer aux tests
+
+### 4. Test
+- Exécute `/test`
+- Si fail persistant après 5 itérations → **STOP** → demande quoi faire
 - **STOP** → attend validation
 
 ### 5. Compound

package/templates/workflow-jira.md

@@ -12,7 +12,8 @@
 ### Variables globales (`.zshrc` ou `.bashrc`)
 
 ```bash
-export ARTE_ATLASSIAN_ROOT_URL="https://mycompany.atlassian.net"  # ou URL on-premise
+# IMPORTANT: URL racine SANS /jira/ à la fin, et SANS espace avant le =
+export ARTE_ATLASSIAN_ROOT_URL="https://mycompany.atlassian.net"
 export ARTE_ATLASSIAN_USER_EMAIL="user@email.com"
 export ARTE_ATLASSIAN_API_TOKEN="your-api-token"
 ```
@@ -31,12 +32,37 @@ export ARTE_ATLASSIAN_PROJECT_NAME="PROJ"
 
 ### Utilisation API
 
+**IMPORTANT** : Pour éviter les erreurs de caractères invisibles dans le terminal, toujours passer par un script temporaire :
+
 ```bash
-# Exemple de requête JIRA
+# Récupérer un ticket
+cat << 'SCRIPT' > /tmp/jira_req.sh
+#!/bin/bash
 curl -s -u "$ARTE_ATLASSIAN_USER_EMAIL:$ARTE_ATLASSIAN_API_TOKEN" \
   "$ARTE_ATLASSIAN_ROOT_URL/rest/api/3/issue/PROJ-123"
+SCRIPT
+chmod +x /tmp/jira_req.sh && /tmp/jira_req.sh
+
+# Recherche JQL (endpoint actuel, l'ancien /search est obsolète)
+cat << 'SCRIPT' > /tmp/jira_req.sh
+#!/bin/bash
+curl -s -G -u "$ARTE_ATLASSIAN_USER_EMAIL:$ARTE_ATLASSIAN_API_TOKEN" \
+  --data-urlencode 'jql=project=PROJ AND fixVersion="1.0.0"' \
+  --data-urlencode 'fields=key,summary,status' \
+  "$ARTE_ATLASSIAN_ROOT_URL/rest/api/3/search/jql"
+SCRIPT
+chmod +x /tmp/jira_req.sh && /tmp/jira_req.sh
 ```
 
+### Troubleshooting
+
+| Erreur | Cause | Solution |
+|--------|-------|----------|
+| `not found` au source | Espace avant `=` | `export VAR="value"` sans espace |
+| `API a été supprimée` | Ancien endpoint | Utiliser `/rest/api/3/search/jql` |
+| `401 Unauthorized` | Token invalide | Régénérer sur id.atlassian.com |
+| `blank argument` | Caractères invisibles | Utiliser un script temporaire (voir exemples ci-dessus) |
+
 ### Fallback
 
 Si l'API REST échoue (erreurs réseau, permissions), utiliser le MCP Atlassian :
@@ -66,17 +92,14 @@ claude mcp add atlassian -- npx -y @anthropic/atlassian-mcp-server
 - Petits commits logiques (conventions dans `git.md`)
 - **STOP** → montre les modifications, attend validation
 
-### 3. Test
-- Lance les tests (commande dans `CLAUDE.md`)
-- Si fail → arrête et fixe CE test uniquement
-- Si le test passe → relance la suite complète
-- Max 5 itérations
-- Si toujours fail → **STOP** → demande quoi faire
-
-### 4. Review
-- Review ton propre code
-- Vérifie : sécurité, performance, lisibilité
-- Propose des améliorations si pertinent
+### 3. Review
+- Exécute `/review`
+- Corrige les problèmes critiques détectés
+- **STOP** → attend validation avant de passer aux tests
+
+### 4. Test
+- Exécute `/test`
+- Si fail persistant après 5 itérations → **STOP** → demande quoi faire
 - **STOP** → attend validation
 
 ### 5. Git

package/.claude/rules/mdma/best-practices.md

@@ -1,50 +0,0 @@
-# Best Practices
-
-## Règle absolue
-
-> **Toujours coder selon les best practices reconnues** pour chaque langage, framework ou librairie utilisé.
-
-## En cas de doute
-
-Si plusieurs approches sont reconnues comme "best practice" :
-
-1. **STOP** - ne pas choisir arbitrairement
-2. Lister les options avec leurs avantages/inconvénients
-3. Demander à l'utilisateur quelle approche privilégier
-
-## Sources de référence
-
-Par ordre de priorité :
-1. Documentation officielle du langage/framework
-2. Style guides officiels (Google, Airbnb, etc.)
-3. Conventions établies dans le projet existant
-
-## MCP recommandé
-
-Le MCP **context7** permet de récupérer la documentation officielle à jour directement dans le contexte.
-
-### Configuration
-
-**mdma-cli** configure automatiquement context7 en scope user lors de `npx mdma-cli add`.
-
-Configuration manuelle si nécessaire :
-
-```bash
-claude mcp add context7 --scope user -- npx -y @upstash/context7-mcp
-```
-
-> **Scope user** : context7 est disponible pour tous vos projets, sans polluer les `.mcp.json` individuels.
-
-### Usage
-
-Inclure `use context7` dans le prompt pour que l'agent récupère la doc à jour :
-- "Implémente l'auth avec NextAuth, use context7"
-- "Ajoute la validation Zod, use context7"
-
-### API Key (optionnel)
-
-Pour des rate limits plus élevés, obtenir une clé gratuite sur [context7.com/dashboard](https://context7.com/dashboard) :
-
-```bash
-claude mcp add context7 --scope user -- npx -y @upstash/context7-mcp --api-key YOUR_API_KEY
-```

package/.claude/rules/mdma/git-default.md

@@ -1,45 +0,0 @@
-# Workflow Git
-
-## Règles absolues
-
-> **Anti-rationalisation** : Ces règles n'ont AUCUNE exception. "JAMAIS" signifie jamais.
-> "C'est juste du gitignore" ou "c'est un petit fix" ne justifie PAS de contourner les règles.
-
-1. **JAMAIS push sur main**
-2. **JAMAIS commit sans branche** `feature/` ou `fix/`
-3. **JAMAIS merge sans PR**
-4. **JAMAIS `git add -A`** : commiter uniquement les fichiers modifiés intentionnellement
-
-Si tu envisages de transgresser une règle → **STOP** → demande à l'utilisateur.
-
-## Process
-
-### Avant de coder
-1. Demander à l'utilisateur s'il souhaite se baser sur `main/master` ou `develop/dev`
-2. Synchroniser la branche de base choisie avec le remote
-3. Si le projet utilise GitHub Issues, créer une issue (titre + description)
-4. Créer une branche depuis la base choisie : `feature/xxx` ou `fix/xxx`
-5. Checkout la nouvelle branche
-
-### Commits
-- Convention : **conventional commits**
-  - `feat:` nouvelle fonctionnalité
-  - `fix:` correction de bug
-  - `docs:` documentation
-  - `refactor:` refactoring
-  - `chore:` maintenance
-  - `test:` ajout/modification de tests
-- Messages clairs et concis
-- Un commit = un changement logique
-
-### Après validation
-1. `git add <fichiers>` (pas -A)
-2. `git commit -m "XXX: description"`. Remplacer XXX par le prefix de conventionnal commits qui correspond le mieux au sujet traité (voir ### Commits)
-3. `git push -u origin <branche>`
-4. `gh pr create --fill`
-5. Attendre validation utilisateur
-6. `gh pr merge --merge --delete-branch`
-7. `git checkout <branche-base> && git pull`
-
-### Tests
-Les tests **DOIVENT** passer avant merge.

package/.claude/rules/mdma/models.md

@@ -1,19 +0,0 @@
-# Sélection des modèles
-
-Utiliser le modèle approprié selon la complexité de la tâche pour optimiser coûts et rapidité.
-
-## Correspondance tâche/modèle
-
-| Tâche | Modèle | Justification |
-|-------|--------|---------------|
-| Tests, build, lint | `haiku` | Exécution simple, pas de raisonnement |
-| Exploration de code, recherche | `sonnet` | Bon équilibre |
-| Implémentation, review, architecture | `opus` | Raisonnement complexe |
-
-## Syntaxe
-
-Spécifier le modèle dans la demande si besoin :
-- "Lance les tests avec haiku"
-- "Explore le code avec sonnet"
-
-Par défaut, l'agent choisit le modèle selon le tableau ci-dessus.

package/.claude/rules/mdma/style.md

@@ -1,42 +0,0 @@
-# Style de réponse
-
-## Profil
-- **Niveau** : Senior
-- **Style** : Détaillé
-
-## Comment répondre
-
-- Réponses détaillées avec contexte
-- Explique les choix importants
-- Propose des alternatives quand pertinent
-- Va droit au but, pas de fioritures inutiles
-
-## Autonomie
-
-- **Demande TOUJOURS avant d'agir**
-- Ne fais rien sans validation explicite
-- Expose le plan, attend "ok", puis agis
-
-## À éviter
-
-- **Obséquiosité** : pas de "Excellent choix!", "Très bonne question!", "C'est une super idée!"
-- Pas de compliments excessifs
-- Pas de formules de politesse superflues
-- Pas d'emojis (sauf si demandé)
-
-## Principes de dev
-
-- **DRY** : Don't Repeat Yourself
-- **YAGNI** : You Ain't Gonna Need It
-- **KISS** : Keep It Simple, Stupid
-
-## Contraintes
-
-### Ne jamais faire
-- Commiter sur main directement
-- Over-engineering
-- Ajouter des features non demandées
-
-### Toujours faire
-- Respecter le workflow défini dans `workflow.md` et `git.md`
-- Garder les solutions simples

package/.claude/rules/mdma/workflow-default.md

@@ -1,65 +0,0 @@
-# Workflow Agent
-
-> **Note** : Ce workflow est agnostique. Pour les commandes spécifiques (test, build, lint), consulte `CLAUDE.md` qui fait référence pour ce projet.
-
-> **Règle de conformité** : Les règles définies ici et dans `git.md` sont ABSOLUES.
-> - Ne jamais rationaliser ("c'est juste un petit fix", "c'est mineur")
-> - Ne jamais faire d'exception, quelle que soit la taille ou nature du changement
-> - En cas de doute → STOP → demander à l'utilisateur
-
-## Étapes obligatoires
-
-### 0. Setup Git
-- Vérifie que tu n'es PAS sur `main` : `git branch --show-current`
-- Si sur `main` → créer une branche AVANT toute modification
-- Ne jamais rationaliser ("c'est juste un petit fix")
-
-### 1. Plan
-- Explore le codebase (structure documentée dans `CLAUDE.md`)
-- Propose un plan d'implémentation
-- **STOP** → attend validation avant de coder
-
-### 2. Code
-- Implémente selon le plan validé
-- Petits commits logiques (conventions dans `git.md`)
-- **STOP** → montre les modifications, attend validation
-
-### 3. Test
-- Lance les tests (commande dans `CLAUDE.md`)
-- Si fail → arrête et fixe CE test uniquement
-- Si le test passe → relance la suite complète
-- Max 5 itérations
-- Si toujours fail → **STOP** → demande quoi faire
-
-#### 3.1 Tests visuels (obligatoire si applicable)
-- **Vérifie** si `.claude/rules/visual-test.md` existe
-- Si oui → exécute `/screenshot` et compare `current/` vs `baseline/`
-- Différence intentionnelle → mettre à jour `baseline/`
-- Régression détectée → **STOP** → corriger avant de continuer
-
-- Si tous les tests passent → **STOP** → attend validation
-
-### 4. Review
-- Review ton propre code
-- Vérifie : sécurité, performance, lisibilité
-- Propose des améliorations si pertinent
-- **STOP** → attend validation
-
-### 5. Compound
-- Consulte `CHANGELOG.md`, `DECISIONS.md`, `LEARNINGS.md` pour contexte
-- Apprends des feedbacks de cette session
-- Note les préférences exprimées pour les appliquer ensuite
-
-### 6. Document
-- Met à jour `CHANGELOG.md` pour chaque feature/fix (obligatoire)
-- Met à jour `LEARNINGS.md` si apprentissage important
-- Met à jour `DECISIONS.md` si décision structurante
-- Si ces fichiers n'existent pas → les créer avec les formats standards :
-  - CHANGELOG.md : [Keep a Changelog](https://keepachangelog.com/)
-  - DECISIONS.md : format ADR (Architecture Decision Records)
-  - LEARNINGS.md : format session avec contexte, décisions, leçons
-- **STOP** → attend validation
-
-### 7. Git
-- Exécute le workflow défini dans `git.md`
-- **STOP** → attend validation avant de commiter