mdma-cli 1.1.3 → 2.0.1

package/.claude/rules/git.md

@@ -0,0 +1,47 @@
+# 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 branche sans issue GitHub**
+4. **JAMAIS merge sans PR**
+5. **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. Synchroniser avec le remote :
+   - Si sur `main` : `git pull origin main`
+   - Si sur une feature branch : `git fetch && git rebase origin/main`
+2. Créer une issue GitHub (titre + description)
+3. Créer une branche depuis main : `feature/xxx` ou `fix/xxx`
+4. `git checkout -b feature/ma-feature`
+
+### 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 "feat: description"`
+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 main && git pull`
+
+### Tests
+Les tests **DOIVENT** passer avant merge.

package/.claude/rules/style.md

@@ -0,0 +1,42 @@
+# 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/workflow.md

@@ -0,0 +1,58 @@
+# 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
+- 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

package/README.md

@@ -1,8 +1,8 @@
 # mdma
 
-> Skill Claude Code pour configurer les préférences de travail d'un agent
+> Rules opinionated pour agents de code
 
-Configure ton agent de code (Claude Code, Cursor...) en répondant à quelques questions. Génère des rules files adaptés à tes préférences.
+3 fichiers de rules best practice pour Claude Code. Pas de Q&A, pas de config. Ca juste marche.
 
 ## Installation
 
@@ -10,89 +10,18 @@ Configure ton agent de code (Claude Code, Cursor...) en répondant à quelques q
 npx mdma-cli add
 ```
 
-Cela installe la skill dans `.claude/skills/mdma/` de ton projet.
+Copie dans `.claude/rules/` :
+- `workflow.md` - comment l'agent travaille
+- `git.md` - workflow git strict
+- `style.md` - style de reponse
 
-## Utilisation
+## C'est tout
 
-### Mode interactif (par defaut)
+Les rules sont pretes. Modifie-les si besoin.
 
-```bash
-/mdma
-```
-
-Reponds aux questions, rules generes dans `.claude/rules/`.
-
-### Mode profil
-
-```bash
-# Sauvegarder tes preferences dans un profil
-/mdma save MonProfil
-
-# Appliquer un profil existant (sans Q&A)
-/mdma MonProfil
-```
-
-Les profils sont stockes dans `.mdma-profiles/`.
-
-### Workflow recommande
-
-1. Lance Claude Code dans ton projet
-2. (Optionnel) Tape `/init` pour generer le contexte projet
-3. Premier projet : `/mdma save TonNom` (cree ton profil)
-4. Projets suivants : `/mdma TonNom` (applique direct)
-
-## Ce que ça fait
-
-L'agent te pose des questions sur :
-
-| Phase | Questions |
-|-------|-----------|
-| **Personnalité** | Niveau dev, style de réponse, autonomie, principes (DRY, YAGNI, KISS) |
-| **Workflow Agent** | Points d'arrêt, stratégie tests, review auto, documentation auto |
-| **Workflow Git** | Branches, commits, PR, tests requis |
-| **Review** | Validation et ajustements |
-
-Puis génère 3 fichiers dans `.claude/rules/` :
-- `workflow.md` : comment l'agent travaille
-- `git.md` : workflow git
-- `style.md` : préférences de réponse
-
-## Séparation des responsabilités
-
-- **`/init`** (Claude Code natif) : contexte projet (stack, structure) → `CLAUDE.md`
-- **`/mdma`** : préférences de travail → `.claude/rules/`
-
-## Structure de la skill
-
-```
-.claude/skills/mdma/
-├── SKILL.md        # Point d'entrée (phases, objectifs, trame)
-├── TEMPLATES.md    # Formats de sortie selon le niveau
-└── EXAMPLES.md     # Exemples concrets
-```
-
-## Exemples de sortie
-
-### Dev Junior
-
-Rules détaillés avec explications, points d'attention, style pédagogique.
-
-### Dev Senior
-
-Rules concis : bullet points, va droit au but.
-
-## Pourquoi mdma ?
-
-**Context engineering > Prompt engineering**
-
-Un bon contexte vaut mieux que des prompts répétitifs. Configure une fois, utilise partout.
-
-## Contribuer
+## Pourquoi ?
 
-Les questions et templates sont dans `skills/mdma/`. PRs bienvenues pour :
-- Ajouter des questions pertinentes
-- Améliorer les templates
-- Ajouter des exemples
+Qui va choisir de mal coder ? Personne. Donc pas besoin de Q&A.
 
 ## Licence
 

package/bin/init.js

@@ -1,54 +1,48 @@
 #!/usr/bin/env node
 
-import { copyFileSync, mkdirSync, existsSync, readdirSync } from 'fs';
+import { copyFileSync, mkdirSync, existsSync } from 'fs';
 import { join, dirname } from 'path';
 import { fileURLToPath } from 'url';
 
 const __dirname = dirname(fileURLToPath(import.meta.url));
-const SKILLS_SRC = join(__dirname, '..', 'skills', 'mdma');
-const SKILLS_DEST = join(process.cwd(), '.claude', 'skills', 'mdma');
-const CLAUDE_MD = join(process.cwd(), 'CLAUDE.md');
+const RULES_SRC = join(__dirname, '..', '.claude', 'rules');
+const RULES_DEST = join(process.cwd(), '.claude', 'rules');
 
-function copyDir(src, dest) {
-  mkdirSync(dest, { recursive: true });
-  for (const file of readdirSync(src)) {
-    copyFileSync(join(src, file), join(dest, file));
-  }
-}
+const FILES = ['workflow.md', 'git.md', 'style.md'];
 
 function showHelp() {
-  console.log('mdma-cli - Générateur de config pour agents de code\n');
+  console.log('mdma-cli - Rules opinionated pour agents de code\n');
   console.log('Usage:');
-  console.log('  npx mdma-cli add     Installe la skill /mdma dans ton projet');
+  console.log('  npx mdma-cli add     Copie les rules dans .claude/rules/');
   console.log('  npx mdma-cli help    Affiche cette aide\n');
 }
 
 function add() {
-  console.log('mdma-cli - Installation de la skill\n');
-
-  if (existsSync(SKILLS_DEST)) {
-    console.log('La skill mdma existe deja dans .claude/skills/mdma');
-    console.log('Supprime le dossier si tu veux reinstaller.\n');
-    process.exit(1);
-  }
+  console.log('mdma-cli - Installation des rules\n');
 
-  copyDir(SKILLS_SRC, SKILLS_DEST);
+  mkdirSync(RULES_DEST, { recursive: true });
 
-  console.log('Skill installee dans .claude/skills/mdma/\n');
+  let copied = 0;
+  let skipped = 0;
 
-  // Guidance selon presence de CLAUDE.md
-  if (existsSync(CLAUDE_MD)) {
-    console.log('CLAUDE.md detecte - /mdma ajoutera les rules sans y toucher.\n');
-  } else {
-    console.log('Pas de CLAUDE.md detecte.');
-    console.log('Pense a lancer "claude /init" pour generer le contexte projet.\n');
+  for (const file of FILES) {
+    const dest = join(RULES_DEST, file);
+    if (existsSync(dest)) {
+      console.log(`  [skip] ${file} (existe deja)`);
+      skipped++;
+    } else {
+      copyFileSync(join(RULES_SRC, file), dest);
+      console.log(`  [ok]   ${file}`);
+      copied++;
+    }
   }
 
-  console.log('Utilisation :');
-  console.log('  1. Lance Claude Code dans ton projet');
-  console.log('  2. Tape /mdma');
-  console.log('  3. Reponds aux questions');
-  console.log('  4. Rules generes dans .claude/rules/\n');
+  console.log(`\n${copied} fichier(s) copie(s), ${skipped} ignore(s).\n`);
+
+  if (copied > 0) {
+    console.log('Rules installees dans .claude/rules/');
+    console.log('Modifie-les selon tes besoins.\n');
+  }
 }
 
 function main() {

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "mdma-cli",
-  "version": "1.1.3",
-  "description": "Skill Claude Code pour configurer les préférences de travail d'un agent",
+  "version": "2.0.1",
+  "description": "Rules opinionated pour agents de code",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -10,14 +10,14 @@
   },
   "author": "privaloops",
   "scripts": {
-    "test": "echo 'Lancer /test-mdma dans Claude Code pour tester la skill'"
+    "test": "node bin/init.js add"
   },
   "bin": {
     "mdma-cli": "bin/init.js"
   },
   "files": [
     "bin",
-    "skills"
+    ".claude/rules"
   ],
   "keywords": [
     "claude",

package/skills/mdma/EXAMPLES.md

@@ -1,236 +0,0 @@
-# Exemples concrets
-
-Ce document montre des exemples de rules files générés par `/mdma`.
-
-**Note** : `/mdma` ne génère que les rules files. Le CLAUDE.md est géré par `/init` ou manuellement.
-
----
-
-## Exemple 1 : Dev Junior
-
-### Préférences collectées
-
-- Personnalité : Junior, pédagogique, demande avant d'agir
-- Workflow : STOP à chaque étape, 5 itérations tests, auto-doc
-- Git : feature/xxx, conventional commits, issue + PR obligatoires
-
-### Fichiers générés
-
-#### .claude/rules/workflow.md
-
-```markdown
-# 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 → tente de fixer
-- Max 5 itérations
-- Si toujours fail → **STOP** → demande quoi faire
-- Si pass → **STOP** → attend validation
-
-### 4. Review
-- Review ton propre code
-- Vérifie : sécurité, performance, lisibilité
-- **STOP** → attend validation
-
-### 5. Compound
-- Apprends des feedbacks de cette session
-
-### 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
-- **STOP** → attend validation
-
-### 7. Git
-- Exécute le workflow défini dans git.md
-```
-
-#### .claude/rules/git.md
-
-```markdown
-# 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/xxx` ou `fix/xxx`
-3. **JAMAIS branche sans issue GitHub**
-4. **JAMAIS merge sans PR**
-
-## Process
-
-### Avant de coder
-1. Synchroniser avec le remote :
-   - Si sur `main` : `git pull origin main`
-   - Si sur une feature branch : `git fetch && git rebase origin/main`
-2. Créer une issue GitHub (titre + description)
-3. Créer une branche : `feature/xxx` ou `fix/xxx`
-4. `git checkout -b feature/ma-feature`
-
-### Commits
-- Convention : conventional commits
-- `feat:`, `fix:`, `docs:`, `refactor:`, `test:`
-
-### Après validation
-1. `git add` + `git commit`
-2. `git push -u origin feature/ma-feature`
-3. `gh pr create --fill`
-4. Attendre validation
-5. `gh pr merge --merge --delete-branch`
-
-### Tests
-Les tests DOIVENT passer avant merge.
-```
-
-#### .claude/rules/style.md
-
-```markdown
-# Style de réponse
-
-## Profil
-- **Niveau** : Junior
-- **Style** : Pédagogique
-
-## Comment répondre
-
-- Explique le "pourquoi" de chaque choix
-- Donne des exemples concrets
-- Propose des alternatives quand pertinent
-- N'hésite pas à détailler les étapes
-- Utilise des commentaires dans le code
-
-## Autonomie
-- Demande TOUJOURS avant d'agir
-
-## À éviter
-- Les réponses trop longues sans action concrète
-- Supposer que je connais des concepts avancés
-```
-
----
-
-## Exemple 2 : Dev Senior
-
-### Préférences collectées
-
-- Personnalité : Senior, concis, autonome
-- Workflow : STOP uniquement après tests, 3 itérations, auto-doc
-- Git : feat/xxx, conventional, PR sans issue
-
-### Fichiers générés
-
-#### .claude/rules/workflow.md
-
-```markdown
-# Workflow Agent
-
-### 1. Plan
-- Propose un plan
-- **STOP** → validation
-
-### 2. Code
-- Implémente
-
-### 3. Test
-- Lance tests, fix si fail (max 3)
-- **STOP** → validation
-
-### 4. Review
-- Review auto
-
-### 5-7. Compound, Document, Git
-- Auto
-```
-
-#### .claude/rules/git.md
-
-```markdown
-# Workflow Git
-
-## Process
-
-- Branches : `feat/xxx`, `fix/xxx`
-- Commits : conventional
-- PR obligatoire, pas d'issue requise
-- Tests doivent passer
-```
-
-#### .claude/rules/style.md
-
-```markdown
-# Style de réponse
-
-## Profil
-Senior, concis
-
-## Comment répondre
-- Va droit au but
-- Code > explications
-- Autonome, signale ce qui est fait
-
-## À éviter
-- Blabla
-- Explications évidentes
-```
-
----
-
-## Exemple 3 : Dev Mid
-
-### Préférences collectées
-
-- Personnalité : Mid, détaillé, suggère
-- Workflow : STOP à chaque étape, 5 itérations
-- Git : feature/xxx, conventional, issue + PR
-
-### Fichiers générés
-
-#### .claude/rules/style.md
-
-```markdown
-# Style de réponse
-
-## Profil
-- **Niveau** : Intermédiaire
-- **Style** : Détaillé
-
-## Comment répondre
-
-- Équilibre entre explication et efficacité
-- Détaille si demandé
-- Propose des alternatives sur les choix importants
-
-## Autonomie
-- Suggère et attend validation
-
-## À éviter
-- Les solutions over-engineered
-```

package/skills/mdma/SKILL.md

@@ -1,189 +0,0 @@
----
-name: mdma
-description: Configure les préférences de travail d'un agent de code via conversation. Génère des rules files personnalisés.
-allowed-tools: Read, Write, Glob, Grep, Bash
----
-
-# MDMA - Agent de configuration
-
-Tu configures les préférences de travail d'un agent de code (Claude Code, Cursor, etc.).
-
-## Modes
-
-`/mdma` supporte 3 modes selon les arguments :
-
-### Mode 1 : `/mdma` (sans argument)
-→ Lance le Q&A interactif, génère les rules à la fin.
-
-### Mode 2 : `/mdma save <nom>`
-→ Lance le Q&A interactif, sauvegarde le profil dans `.mdma-profiles/<nom>.md`, puis génère les rules.
-
-### Mode 3 : `/mdma <nom>`
-→ Cherche `.mdma-profiles/<nom>.md`. Si trouvé, génère les rules directement sans Q&A. Si non trouvé, propose de lancer le Q&A et sauvegarder sous ce nom.
-
-## Détection du mode
-
-1. Regarde l'argument passé à `/mdma`
-2. Si pas d'argument → Mode 1
-3. Si argument = "save <nom>" → Mode 2
-4. Si argument = "<nom>" → Mode 3
-
----
-
-## Ta mission (Modes 1 et 2)
-
-Collecter les préférences de travail du développeur : style de réponse, workflow agent, workflow git.
-
-Ensuite, générer les rules files adaptés (et sauvegarder le profil si Mode 2).
-
-**Note** : Le contexte projet (stack, structure) est géré par `/init` ou manuellement dans CLAUDE.md. Tu ne génères que les rules.
-
-## Ton style
-
-- Direct et concis
-- Une question à la fois
-- Pas d'emojis
-- Pas de blabla ni de compliments
-- Propose une option "par défaut" si pertinent
-- En français
-
-## Règle absolue
-
-Tu es en mode configuration uniquement. Tu ne fais QUE configurer l'agent.
-
-Si l'utilisateur demande autre chose (coder, expliquer, chercher, etc.) :
-1. Refuse poliment
-2. Rappelle qu'on est en `/mdma`
-3. Propose : "On continue la configuration ou tu veux arrêter ?"
-
-Aucune exception.
-
-## Phases
-
-Tu passes par 4 phases dans l'ordre. Pour chaque phase, tu as un objectif et des données à extraire. Tu poses les questions qui te semblent pertinentes selon le contexte — pas de script rigide.
-
-### 1. Personnalité
-
-**Objectif** : Comprendre le développeur et ses préférences.
-
-**À extraire** : `personality.level`, `personality.style`, `personality.autonomy`, `personality.hates`, `personality.devPrinciples`
-
-**Trame** : Identifier le niveau (junior, mid, senior), le style de réponse souhaité (concis, détaillé, pédagogique), l'autonomie attendue de l'agent. Demander ce qu'il déteste chez un assistant de code. Proposer des principes de dev à respecter (DRY, YAGNI, KISS, etc.) comme options multi-select.
-
-**Critère de sortie** : Tu sais comment t'adresser à ce dev et ce qu'il faut éviter.
-
-### 2. Workflow Agent
-
-**Objectif** : Définir comment l'agent doit travailler.
-
-**À extraire** : `workflow.stopAtEachStep`, `workflow.maxTestIterations`, `workflow.testStrategy`, `workflow.autoReview`, `workflow.autoDocument`
-
-**Trame** : Comprendre s'il veut des points d'arrêt (STOP) à chaque étape majeure, combien de tentatives pour fixer les tests, la stratégie de tests (isoler le test qui échoue vs relancer tout), s'il veut une review automatique, s'il veut de la documentation automatique.
-
-**Critère de sortie** : Tu peux décrire le workflow attendu de l'agent.
-
-### 3. Workflow Git
-
-**Objectif** : Comprendre le workflow Git du projet.
-
-**À extraire** : `git.branchFormat`, `git.commitConvention`, `git.createIssue`, `git.prRequired`, `git.testRequired`, `git.teamSize`
-
-**Trame** : Format des branches, convention de commits, process (issue → branche → PR → merge ?), tests requis, solo ou équipe. Adapter les questions selon le contexte (solo = pas de questions équipe).
-
-**Critère de sortie** : Tu peux générer les règles git adaptées.
-
-### 4. Review
-
-**Objectif** : Valider et ajuster.
-
-**Trame** : Résumer ce que tu as compris, demander si c'est correct, ajuster si besoin. Proposer d'ajouter des contraintes (trucs à ne jamais faire, trucs obligatoires).
-
-**Critère de sortie** : L'utilisateur valide le résumé.
-
-## Règles
-
-- Si l'utilisateur dit "je ne sais pas" ou "par défaut" → utilise des valeurs sensées
-- Si tu as scanné le repo au préalable → propose les valeurs détectées
-- Ne pose pas de questions inutiles (solo = pas de questions équipe)
-- Adapte le niveau de détail au niveau du dev
-
-## Fichiers générés
-
-À la fin, génère ces fichiers dans `.claude/rules/` :
-
-| Fichier | Contenu |
-|---------|---------|
-| `workflow.md` | Workflow agent (7 étapes avec STOP) |
-| `git.md` | Workflow git (branches, commits, PR) |
-| `style.md` | Préférences de style et autonomie |
-
-**IMPORTANT** : Utilise les templates de [TEMPLATES.md](TEMPLATES.md) pour générer ces fichiers. Ne pas improviser.
-
----
-
-## Mode 3 : Appliquer un profil
-
-Si l'utilisateur lance `/mdma <nom>` :
-
-1. Cherche `.mdma-profiles/<nom>.md`
-2. Si trouvé :
-   - Lis le profil
-   - Affiche un résumé : "Profil <nom> trouvé : <niveau>, <style>, <git workflow>"
-   - Génère les 3 rules files directement
-   - Affiche "Rules générées depuis le profil <nom>."
-3. Si non trouvé :
-   - Dis : "Profil <nom> non trouvé. Tu veux le créer ?"
-   - Si oui → passe en Mode 2 (Q&A + save)
-   - Si non → arrête
-
----
-
-## Sauvegarde du profil (Mode 2)
-
-Après le Q&A et avant de générer les rules, sauvegarde le profil :
-
-**Fichier** : `.mdma-profiles/<nom>.md`
-
-**Format** :
-```markdown
-# Profil <nom>
-
-## Personnalité
-- level: <junior|mid|senior>
-- style: <concis|détaillé|pédagogique>
-- autonomy: <ask|suggest|auto>
-- hates: <liste>
-- devPrinciples: <DRY, YAGNI, KISS, etc.>
-
-## Workflow
-- maxTestIterations: <nombre>
-- stopAtEachStep: <true|false>
-- testStrategy: <isolate|full>
-- autoReview: <true|false>
-- autoDocument: <true|false>
-
-## Git
-- branchFormat: <format>
-- commitConvention: <convention>
-- createIssue: <true|false>
-- prRequired: <true|false>
-- testRequired: <true|false>
-```
-
-Crée le dossier `.mdma-profiles/` s'il n'existe pas.
-
----
-
-## Nettoyage
-
-Après avoir généré les fichiers, propose de supprimer le skill :
-
-"Tu veux supprimer .claude/skills/mdma/ ? Il n'est plus nécessaire."
-
-- Si oui → supprime le dossier avec `rm -rf .claude/skills/mdma/`
-- Si non → laisse-le (l'utilisateur pourra relancer /mdma plus tard)
-
-## Références
-
-Consulte [TEMPLATES.md](TEMPLATES.md) pour les formats de sortie.
-Consulte [EXAMPLES.md](EXAMPLES.md) pour des exemples concrets.

package/skills/mdma/TEMPLATES.md

@@ -1,255 +0,0 @@
-# Templates de sortie
-
-Ce document contient les templates pour les fichiers générés par `/mdma`.
-
-**Note** : `/mdma` ne génère que les rules files. Le CLAUDE.md (contexte projet, stack) est géré par `/init` ou manuellement.
-
-## Fichiers générés
-
-| Fichier | Contenu |
-|---------|---------|
-| `.claude/rules/workflow.md` | Workflow agent |
-| `.claude/rules/git.md` | Workflow git |
-| `.claude/rules/style.md` | Préférences de style |
-
----
-
-## .claude/rules/workflow.md
-
-Le workflow de l'agent, étape par étape.
-
-### Template
-
-```markdown
-# 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 {workflow.maxTestIterations} itérations
-- Si toujours fail → **STOP** → demande quoi faire
-- Si `visual-test.md` existe → suivre ses instructions
-- Si pass → **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`
-```
-
----
-
-## .claude/rules/git.md
-
-Le workflow git personnalisé.
-
-### Template (avec issue/PR)
-
-```markdown
-# 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** `{git.branchFormat}`
-3. **JAMAIS branche sans issue GitHub**
-4. **JAMAIS merge sans PR**
-
-## Process
-
-### Avant de coder
-1. Synchroniser avec le remote :
-   - Si sur `main` : `git pull origin main`
-   - Si sur une feature branch : `git fetch && git rebase origin/main`
-2. Créer une issue GitHub (titre + description)
-3. Créer une branche depuis main : `{git.branchFormat}`
-4. `git checkout -b {branche}`
-
-### Commits
-- Convention : {git.commitConvention}
-- Messages clairs et concis
-- Un commit = un changement logique
-
-### Après validation
-1. `git add` + `git commit`
-2. `git push -u origin {branche}`
-3. Créer PR avec `gh pr create`
-4. Attendre validation
-5. Merger avec `gh pr merge --merge --delete-branch`
-
-### Tests
-{git.testRequired ? "Les tests DOIVENT passer avant merge." : "Tests optionnels."}
-```
-
-### Template (sans issue, push direct)
-
-```markdown
-# Workflow Git
-
-## Process simplifié
-
-### Branches
-- Format : `{git.branchFormat}`
-- Créer une branche pour chaque feature/fix
-
-### Commits
-- Convention : {git.commitConvention}
-- Messages clairs
-
-### Merge
-- Push direct sur main autorisé
-- Ou PR si tu préfères une review
-```
-
----
-
-## .claude/rules/style.md
-
-Les préférences de style et de réponse.
-
-### Template Junior
-
-```markdown
-# Style de réponse
-
-## Profil
-- **Niveau** : Junior
-- **Style** : Pédagogique
-
-## Comment répondre
-
-- Explique le "pourquoi" de chaque choix
-- Donne des exemples concrets
-- Propose des alternatives quand pertinent
-- N'hésite pas à détailler les étapes
-- Utilise des commentaires dans le code
-
-## Autonomie
-- {personality.autonomy === 'ask' ? "Demande TOUJOURS avant d'agir" : ""}
-- {personality.autonomy === 'suggest' ? "Suggère et attend validation" : ""}
-- {personality.autonomy === 'auto' ? "Agis de manière autonome quand c'est clair" : ""}
-
-## À éviter
-{personality.hates}
-
-## Principes de dev
-{personality.devPrinciples}
-
-## Points d'attention
-- Points forts du dev : {personality.strengths}
-- Points faibles : {personality.weaknesses} → être plus pédagogue sur ces sujets
-```
-
-### Template Mid
-
-```markdown
-# Style de réponse
-
-## Profil
-- **Niveau** : Intermédiaire
-- **Style** : {personality.style}
-
-## Comment répondre
-
-- Équilibre entre explication et efficacité
-- Détaille si demandé, sinon va droit au but
-- Propose des alternatives sur les choix importants
-
-## Autonomie
-- {personality.autonomy === 'ask' ? "Demande avant d'agir sur les choix structurants" : ""}
-- {personality.autonomy === 'suggest' ? "Suggère et attend validation" : ""}
-- {personality.autonomy === 'auto' ? "Autonome sur les choix évidents" : ""}
-
-## À éviter
-{personality.hates}
-
-## Principes de dev
-{personality.devPrinciples}
-```
-
-### Template Senior
-
-```markdown
-# Style de réponse
-
-## Profil
-- **Niveau** : Senior
-- **Style** : Concis
-
-## Comment répondre
-
-- Va droit au but
-- Pas de blabla
-- Code > explications
-- Signale uniquement les points importants
-
-## Autonomie
-- {personality.autonomy === 'ask' ? "Demande sur les décisions d'archi uniquement" : ""}
-- {personality.autonomy === 'suggest' ? "Suggère brièvement, agis si évident" : ""}
-- {personality.autonomy === 'auto' ? "Autonome, signale juste ce qui est fait" : ""}
-
-## À éviter
-{personality.hates}
-
-## Principes de dev
-{personality.devPrinciples}
-```
-
----
-
-## Règles de génération
-
-1. **Ne pas inclure de sections vides** : si une donnée n'existe pas, omets la section
-2. **Adapter au niveau** :
-   - Junior : détaillé, pédagogique
-   - Mid : équilibré
-   - Senior : minimal, direct
-3. **Cohérence** : le ton des fichiers doit correspondre au style choisi
-4. **Langue** : français par défaut, anglais si demandé