mdma-cli 1.2.0 → 2.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/rules/git.md +47 -0
- package/.claude/rules/style.md +42 -0
- package/.claude/rules/workflow.md +65 -0
- package/README.md +10 -78
- package/bin/init.js +26 -32
- package/package.json +4 -4
- package/skills/mdma/EXAMPLES.md +0 -241
- package/skills/mdma/SKILL.md +0 -257
- package/skills/mdma/TEMPLATES.md +0 -261
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Workflow Git
|
|
2
|
+
|
|
3
|
+
## Règles absolues
|
|
4
|
+
|
|
5
|
+
> **Anti-rationalisation** : Ces règles n'ont AUCUNE exception. "JAMAIS" signifie jamais.
|
|
6
|
+
> "C'est juste du gitignore" ou "c'est un petit fix" ne justifie PAS de contourner les règles.
|
|
7
|
+
|
|
8
|
+
1. **JAMAIS push sur main**
|
|
9
|
+
2. **JAMAIS commit sans branche** `feature/` ou `fix/`
|
|
10
|
+
3. **JAMAIS branche sans issue GitHub**
|
|
11
|
+
4. **JAMAIS merge sans PR**
|
|
12
|
+
5. **JAMAIS `git add -A`** : commiter uniquement les fichiers modifiés intentionnellement
|
|
13
|
+
|
|
14
|
+
Si tu envisages de transgresser une règle → **STOP** → demande à l'utilisateur.
|
|
15
|
+
|
|
16
|
+
## Process
|
|
17
|
+
|
|
18
|
+
### Avant de coder
|
|
19
|
+
1. Synchroniser avec le remote :
|
|
20
|
+
- Si sur `main` : `git pull origin main`
|
|
21
|
+
- Si sur une feature branch : `git fetch && git rebase origin/main`
|
|
22
|
+
2. Créer une issue GitHub (titre + description)
|
|
23
|
+
3. Créer une branche depuis main : `feature/xxx` ou `fix/xxx`
|
|
24
|
+
4. `git checkout -b feature/ma-feature`
|
|
25
|
+
|
|
26
|
+
### Commits
|
|
27
|
+
- Convention : **conventional commits**
|
|
28
|
+
- `feat:` nouvelle fonctionnalité
|
|
29
|
+
- `fix:` correction de bug
|
|
30
|
+
- `docs:` documentation
|
|
31
|
+
- `refactor:` refactoring
|
|
32
|
+
- `chore:` maintenance
|
|
33
|
+
- `test:` ajout/modification de tests
|
|
34
|
+
- Messages clairs et concis
|
|
35
|
+
- Un commit = un changement logique
|
|
36
|
+
|
|
37
|
+
### Après validation
|
|
38
|
+
1. `git add <fichiers>` (pas -A)
|
|
39
|
+
2. `git commit -m "feat: description"`
|
|
40
|
+
3. `git push -u origin <branche>`
|
|
41
|
+
4. `gh pr create --fill`
|
|
42
|
+
5. Attendre validation utilisateur
|
|
43
|
+
6. `gh pr merge --merge --delete-branch`
|
|
44
|
+
7. `git checkout main && git pull`
|
|
45
|
+
|
|
46
|
+
### Tests
|
|
47
|
+
Les tests **DOIVENT** passer avant merge.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
# Style de réponse
|
|
2
|
+
|
|
3
|
+
## Profil
|
|
4
|
+
- **Niveau** : Senior
|
|
5
|
+
- **Style** : Détaillé
|
|
6
|
+
|
|
7
|
+
## Comment répondre
|
|
8
|
+
|
|
9
|
+
- Réponses détaillées avec contexte
|
|
10
|
+
- Explique les choix importants
|
|
11
|
+
- Propose des alternatives quand pertinent
|
|
12
|
+
- Va droit au but, pas de fioritures inutiles
|
|
13
|
+
|
|
14
|
+
## Autonomie
|
|
15
|
+
|
|
16
|
+
- **Demande TOUJOURS avant d'agir**
|
|
17
|
+
- Ne fais rien sans validation explicite
|
|
18
|
+
- Expose le plan, attend "ok", puis agis
|
|
19
|
+
|
|
20
|
+
## À éviter
|
|
21
|
+
|
|
22
|
+
- **Obséquiosité** : pas de "Excellent choix!", "Très bonne question!", "C'est une super idée!"
|
|
23
|
+
- Pas de compliments excessifs
|
|
24
|
+
- Pas de formules de politesse superflues
|
|
25
|
+
- Pas d'emojis (sauf si demandé)
|
|
26
|
+
|
|
27
|
+
## Principes de dev
|
|
28
|
+
|
|
29
|
+
- **DRY** : Don't Repeat Yourself
|
|
30
|
+
- **YAGNI** : You Ain't Gonna Need It
|
|
31
|
+
- **KISS** : Keep It Simple, Stupid
|
|
32
|
+
|
|
33
|
+
## Contraintes
|
|
34
|
+
|
|
35
|
+
### Ne jamais faire
|
|
36
|
+
- Commiter sur main directement
|
|
37
|
+
- Over-engineering
|
|
38
|
+
- Ajouter des features non demandées
|
|
39
|
+
|
|
40
|
+
### Toujours faire
|
|
41
|
+
- Respecter le workflow défini dans `workflow.md` et `git.md`
|
|
42
|
+
- Garder les solutions simples
|
|
@@ -0,0 +1,65 @@
|
|
|
1
|
+
# Workflow Agent
|
|
2
|
+
|
|
3
|
+
> **Note** : Ce workflow est agnostique. Pour les commandes spécifiques (test, build, lint), consulte `CLAUDE.md` qui fait référence pour ce projet.
|
|
4
|
+
|
|
5
|
+
> **Règle de conformité** : Les règles définies ici et dans `git.md` sont ABSOLUES.
|
|
6
|
+
> - Ne jamais rationaliser ("c'est juste un petit fix", "c'est mineur")
|
|
7
|
+
> - Ne jamais faire d'exception, quelle que soit la taille ou nature du changement
|
|
8
|
+
> - En cas de doute → STOP → demander à l'utilisateur
|
|
9
|
+
|
|
10
|
+
## Étapes obligatoires
|
|
11
|
+
|
|
12
|
+
### 0. Setup Git
|
|
13
|
+
- Vérifie que tu n'es PAS sur `main` : `git branch --show-current`
|
|
14
|
+
- Si sur `main` → créer une branche AVANT toute modification
|
|
15
|
+
- Ne jamais rationaliser ("c'est juste un petit fix")
|
|
16
|
+
|
|
17
|
+
### 1. Plan
|
|
18
|
+
- Explore le codebase (structure documentée dans `CLAUDE.md`)
|
|
19
|
+
- Propose un plan d'implémentation
|
|
20
|
+
- **STOP** → attend validation avant de coder
|
|
21
|
+
|
|
22
|
+
### 2. Code
|
|
23
|
+
- Implémente selon le plan validé
|
|
24
|
+
- Petits commits logiques (conventions dans `git.md`)
|
|
25
|
+
- **STOP** → montre les modifications, attend validation
|
|
26
|
+
|
|
27
|
+
### 3. Test
|
|
28
|
+
- Lance les tests (commande dans `CLAUDE.md`)
|
|
29
|
+
- Si fail → arrête et fixe CE test uniquement
|
|
30
|
+
- Si le test passe → relance la suite complète
|
|
31
|
+
- Max 5 itérations
|
|
32
|
+
- Si toujours fail → **STOP** → demande quoi faire
|
|
33
|
+
|
|
34
|
+
#### 3.1 Tests visuels (obligatoire si applicable)
|
|
35
|
+
- **Vérifie** si `.claude/rules/visual-test.md` existe
|
|
36
|
+
- Si oui → exécute `/screenshot` et compare `current/` vs `baseline/`
|
|
37
|
+
- Différence intentionnelle → mettre à jour `baseline/`
|
|
38
|
+
- Régression détectée → **STOP** → corriger avant de continuer
|
|
39
|
+
|
|
40
|
+
- Si tous les tests passent → **STOP** → attend validation
|
|
41
|
+
|
|
42
|
+
### 4. Review
|
|
43
|
+
- Review ton propre code
|
|
44
|
+
- Vérifie : sécurité, performance, lisibilité
|
|
45
|
+
- Propose des améliorations si pertinent
|
|
46
|
+
- **STOP** → attend validation
|
|
47
|
+
|
|
48
|
+
### 5. Compound
|
|
49
|
+
- Consulte `CHANGELOG.md`, `DECISIONS.md`, `LEARNINGS.md` pour contexte
|
|
50
|
+
- Apprends des feedbacks de cette session
|
|
51
|
+
- Note les préférences exprimées pour les appliquer ensuite
|
|
52
|
+
|
|
53
|
+
### 6. Document
|
|
54
|
+
- Met à jour `CHANGELOG.md` pour chaque feature/fix (obligatoire)
|
|
55
|
+
- Met à jour `LEARNINGS.md` si apprentissage important
|
|
56
|
+
- Met à jour `DECISIONS.md` si décision structurante
|
|
57
|
+
- Si ces fichiers n'existent pas → les créer avec les formats standards :
|
|
58
|
+
- CHANGELOG.md : [Keep a Changelog](https://keepachangelog.com/)
|
|
59
|
+
- DECISIONS.md : format ADR (Architecture Decision Records)
|
|
60
|
+
- LEARNINGS.md : format session avec contexte, décisions, leçons
|
|
61
|
+
- **STOP** → attend validation
|
|
62
|
+
|
|
63
|
+
### 7. Git
|
|
64
|
+
- Exécute le workflow défini dans `git.md`
|
|
65
|
+
- **STOP** → attend validation avant de commiter
|
package/README.md
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# mdma
|
|
2
2
|
|
|
3
|
-
>
|
|
3
|
+
> Rules opinionated pour agents de code
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
3 fichiers de rules best practice pour Claude Code. Pas de Q&A, pas de config. Ca juste marche.
|
|
6
6
|
|
|
7
7
|
## Installation
|
|
8
8
|
|
|
@@ -10,86 +10,18 @@ Configure ton agent de code (Claude Code, Cursor...) en répondant à quelques q
|
|
|
10
10
|
npx mdma-cli add
|
|
11
11
|
```
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Copie dans `.claude/rules/` :
|
|
14
|
+
- `workflow.md` - comment l'agent travaille
|
|
15
|
+
- `git.md` - workflow git strict
|
|
16
|
+
- `style.md` - style de reponse
|
|
14
17
|
|
|
15
|
-
##
|
|
18
|
+
## C'est tout
|
|
16
19
|
|
|
17
|
-
|
|
20
|
+
Les rules sont pretes. Modifie-les si besoin.
|
|
18
21
|
|
|
19
|
-
|
|
20
|
-
/mdma
|
|
21
|
-
```
|
|
22
|
-
|
|
23
|
-
Reponds aux questions, rules generes dans `.claude/rules/`.
|
|
24
|
-
A la fin, propose de sauvegarder ton profil via dialogue fichier (Finder/Explorer).
|
|
25
|
-
|
|
26
|
-
### Importer un profil existant
|
|
27
|
-
|
|
28
|
-
```bash
|
|
29
|
-
/mdma import
|
|
30
|
-
```
|
|
31
|
-
|
|
32
|
-
Ouvre un dialogue fichier pour selectionner un profil `.md` existant, puis genere les rules sans Q&A.
|
|
33
|
-
|
|
34
|
-
### Workflow recommande
|
|
35
|
-
|
|
36
|
-
1. Lance Claude Code dans ton projet
|
|
37
|
-
2. (Optionnel) Tape `/init` pour generer le contexte projet
|
|
38
|
-
3. Premier projet : `/mdma` puis sauvegarde ton profil quelque part (cloud, cle USB...)
|
|
39
|
-
4. Projets suivants : `/mdma import` pour reutiliser ton profil
|
|
40
|
-
|
|
41
|
-
## Ce que ça fait
|
|
42
|
-
|
|
43
|
-
L'agent te pose des questions sur :
|
|
44
|
-
|
|
45
|
-
| Phase | Questions |
|
|
46
|
-
|-------|-----------|
|
|
47
|
-
| **Personnalité** | Niveau dev, style de réponse, autonomie, principes (DRY, YAGNI, KISS) |
|
|
48
|
-
| **Workflow Agent** | Points d'arrêt, stratégie tests, review auto, documentation auto |
|
|
49
|
-
| **Workflow Git** | Branches, commits, PR, tests requis |
|
|
50
|
-
| **Review** | Validation et ajustements |
|
|
51
|
-
|
|
52
|
-
Puis génère 3 fichiers dans `.claude/rules/` :
|
|
53
|
-
- `workflow.md` : comment l'agent travaille
|
|
54
|
-
- `git.md` : workflow git
|
|
55
|
-
- `style.md` : préférences de réponse
|
|
56
|
-
|
|
57
|
-
## Séparation des responsabilités
|
|
58
|
-
|
|
59
|
-
- **`/init`** (Claude Code natif) : contexte projet (stack, structure) → `CLAUDE.md`
|
|
60
|
-
- **`/mdma`** : préférences de travail → `.claude/rules/`
|
|
61
|
-
|
|
62
|
-
## Structure de la skill
|
|
63
|
-
|
|
64
|
-
```
|
|
65
|
-
.claude/skills/mdma/
|
|
66
|
-
├── SKILL.md # Point d'entrée (phases, objectifs, trame)
|
|
67
|
-
├── TEMPLATES.md # Formats de sortie selon le niveau
|
|
68
|
-
└── EXAMPLES.md # Exemples concrets
|
|
69
|
-
```
|
|
70
|
-
|
|
71
|
-
## Exemples de sortie
|
|
72
|
-
|
|
73
|
-
### Dev Junior
|
|
74
|
-
|
|
75
|
-
Rules détaillés avec explications, points d'attention, style pédagogique.
|
|
76
|
-
|
|
77
|
-
### Dev Senior
|
|
78
|
-
|
|
79
|
-
Rules concis : bullet points, va droit au but.
|
|
80
|
-
|
|
81
|
-
## Pourquoi mdma ?
|
|
82
|
-
|
|
83
|
-
**Context engineering > Prompt engineering**
|
|
84
|
-
|
|
85
|
-
Un bon contexte vaut mieux que des prompts répétitifs. Configure une fois, utilise partout.
|
|
86
|
-
|
|
87
|
-
## Contribuer
|
|
22
|
+
## Pourquoi ?
|
|
88
23
|
|
|
89
|
-
|
|
90
|
-
- Ajouter des questions pertinentes
|
|
91
|
-
- Améliorer les templates
|
|
92
|
-
- Ajouter des exemples
|
|
24
|
+
Qui va choisir de mal coder ? Personne. Donc pas besoin de Q&A.
|
|
93
25
|
|
|
94
26
|
## Licence
|
|
95
27
|
|
package/bin/init.js
CHANGED
|
@@ -1,54 +1,48 @@
|
|
|
1
1
|
#!/usr/bin/env node
|
|
2
2
|
|
|
3
|
-
import { copyFileSync, mkdirSync, existsSync
|
|
3
|
+
import { copyFileSync, mkdirSync, existsSync } from 'fs';
|
|
4
4
|
import { join, dirname } from 'path';
|
|
5
5
|
import { fileURLToPath } from 'url';
|
|
6
6
|
|
|
7
7
|
const __dirname = dirname(fileURLToPath(import.meta.url));
|
|
8
|
-
const
|
|
9
|
-
const
|
|
10
|
-
const CLAUDE_MD = join(process.cwd(), 'CLAUDE.md');
|
|
8
|
+
const RULES_SRC = join(__dirname, '..', '.claude', 'rules');
|
|
9
|
+
const RULES_DEST = join(process.cwd(), '.claude', 'rules');
|
|
11
10
|
|
|
12
|
-
|
|
13
|
-
mkdirSync(dest, { recursive: true });
|
|
14
|
-
for (const file of readdirSync(src)) {
|
|
15
|
-
copyFileSync(join(src, file), join(dest, file));
|
|
16
|
-
}
|
|
17
|
-
}
|
|
11
|
+
const FILES = ['workflow.md', 'git.md', 'style.md'];
|
|
18
12
|
|
|
19
13
|
function showHelp() {
|
|
20
|
-
console.log('mdma-cli -
|
|
14
|
+
console.log('mdma-cli - Rules opinionated pour agents de code\n');
|
|
21
15
|
console.log('Usage:');
|
|
22
|
-
console.log(' npx mdma-cli add
|
|
16
|
+
console.log(' npx mdma-cli add Copie les rules dans .claude/rules/');
|
|
23
17
|
console.log(' npx mdma-cli help Affiche cette aide\n');
|
|
24
18
|
}
|
|
25
19
|
|
|
26
20
|
function add() {
|
|
27
|
-
console.log('mdma-cli - Installation
|
|
28
|
-
|
|
29
|
-
if (existsSync(SKILLS_DEST)) {
|
|
30
|
-
console.log('La skill mdma existe deja dans .claude/skills/mdma');
|
|
31
|
-
console.log('Supprime le dossier si tu veux reinstaller.\n');
|
|
32
|
-
process.exit(1);
|
|
33
|
-
}
|
|
21
|
+
console.log('mdma-cli - Installation des rules\n');
|
|
34
22
|
|
|
35
|
-
|
|
23
|
+
mkdirSync(RULES_DEST, { recursive: true });
|
|
36
24
|
|
|
37
|
-
|
|
25
|
+
let copied = 0;
|
|
26
|
+
let skipped = 0;
|
|
38
27
|
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
}
|
|
43
|
-
|
|
44
|
-
|
|
28
|
+
for (const file of FILES) {
|
|
29
|
+
const dest = join(RULES_DEST, file);
|
|
30
|
+
if (existsSync(dest)) {
|
|
31
|
+
console.log(` [skip] ${file} (existe deja)`);
|
|
32
|
+
skipped++;
|
|
33
|
+
} else {
|
|
34
|
+
copyFileSync(join(RULES_SRC, file), dest);
|
|
35
|
+
console.log(` [ok] ${file}`);
|
|
36
|
+
copied++;
|
|
37
|
+
}
|
|
45
38
|
}
|
|
46
39
|
|
|
47
|
-
console.log(
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
40
|
+
console.log(`\n${copied} fichier(s) copie(s), ${skipped} ignore(s).\n`);
|
|
41
|
+
|
|
42
|
+
if (copied > 0) {
|
|
43
|
+
console.log('Rules installees dans .claude/rules/');
|
|
44
|
+
console.log('Modifie-les selon tes besoins.\n');
|
|
45
|
+
}
|
|
52
46
|
}
|
|
53
47
|
|
|
54
48
|
function main() {
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "mdma-cli",
|
|
3
|
-
"version": "
|
|
4
|
-
"description": "
|
|
3
|
+
"version": "2.0.2",
|
|
4
|
+
"description": "Rules opinionated pour agents de code",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"license": "MIT",
|
|
7
7
|
"repository": {
|
|
@@ -10,14 +10,14 @@
|
|
|
10
10
|
},
|
|
11
11
|
"author": "privaloops",
|
|
12
12
|
"scripts": {
|
|
13
|
-
"test": "
|
|
13
|
+
"test": "node bin/init.js add"
|
|
14
14
|
},
|
|
15
15
|
"bin": {
|
|
16
16
|
"mdma-cli": "bin/init.js"
|
|
17
17
|
},
|
|
18
18
|
"files": [
|
|
19
19
|
"bin",
|
|
20
|
-
"
|
|
20
|
+
".claude/rules"
|
|
21
21
|
],
|
|
22
22
|
"keywords": [
|
|
23
23
|
"claude",
|
package/skills/mdma/EXAMPLES.md
DELETED
|
@@ -1,241 +0,0 @@
|
|
|
1
|
-
# Exemples concrets
|
|
2
|
-
|
|
3
|
-
Ce document montre des exemples de rules files générés par `/mdma`.
|
|
4
|
-
|
|
5
|
-
**Note** : `/mdma` ne génère que les rules files. Le CLAUDE.md est géré par `/init` ou manuellement.
|
|
6
|
-
|
|
7
|
-
---
|
|
8
|
-
|
|
9
|
-
## Exemple 1 : Dev Junior
|
|
10
|
-
|
|
11
|
-
### Préférences collectées
|
|
12
|
-
|
|
13
|
-
- Personnalité : Junior, pédagogique, demande avant d'agir
|
|
14
|
-
- Workflow : STOP à chaque étape, 5 itérations tests, auto-doc
|
|
15
|
-
- Git : feature/xxx, conventional commits, issue + PR obligatoires
|
|
16
|
-
|
|
17
|
-
### Fichiers générés
|
|
18
|
-
|
|
19
|
-
#### .claude/rules/workflow.md
|
|
20
|
-
|
|
21
|
-
```markdown
|
|
22
|
-
# Workflow Agent
|
|
23
|
-
|
|
24
|
-
> **Note** : Ce workflow est agnostique. Pour les commandes spécifiques (test, build, lint), consulte `CLAUDE.md` qui fait référence pour ce projet.
|
|
25
|
-
|
|
26
|
-
> **Règle de conformité** : Les règles définies ici et dans `git.md` sont ABSOLUES.
|
|
27
|
-
> - Ne jamais rationaliser ("c'est juste un petit fix", "c'est mineur")
|
|
28
|
-
> - Ne jamais faire d'exception, quelle que soit la taille ou nature du changement
|
|
29
|
-
> - En cas de doute → STOP → demander à l'utilisateur
|
|
30
|
-
|
|
31
|
-
## Étapes obligatoires
|
|
32
|
-
|
|
33
|
-
### 0. Setup Git
|
|
34
|
-
- Vérifie que tu n'es PAS sur `main` : `git branch --show-current`
|
|
35
|
-
- Si sur `main` → créer une branche AVANT toute modification
|
|
36
|
-
- Ne jamais rationaliser ("c'est juste un petit fix")
|
|
37
|
-
|
|
38
|
-
### 1. Plan
|
|
39
|
-
- Explore le codebase (structure documentée dans `CLAUDE.md`)
|
|
40
|
-
- Propose un plan d'implémentation
|
|
41
|
-
- **STOP** → attend validation avant de coder
|
|
42
|
-
|
|
43
|
-
### 2. Code
|
|
44
|
-
- Implémente selon le plan validé
|
|
45
|
-
- Petits commits logiques (conventions dans `git.md`)
|
|
46
|
-
- **STOP** → montre les modifications, attend validation
|
|
47
|
-
|
|
48
|
-
### 3. Test
|
|
49
|
-
- Lance les tests (commande dans `CLAUDE.md`)
|
|
50
|
-
- Si fail → tente de fixer
|
|
51
|
-
- Max 5 itérations
|
|
52
|
-
- Si toujours fail → **STOP** → demande quoi faire
|
|
53
|
-
|
|
54
|
-
#### 3.1 Tests visuels (obligatoire si applicable)
|
|
55
|
-
- **Vérifie** si `.claude/rules/visual-test.md` existe
|
|
56
|
-
- Si oui → exécute les tests visuels
|
|
57
|
-
|
|
58
|
-
- Si tous les tests passent → **STOP** → attend validation
|
|
59
|
-
|
|
60
|
-
### 4. Review
|
|
61
|
-
- Review ton propre code
|
|
62
|
-
- Vérifie : sécurité, performance, lisibilité
|
|
63
|
-
- **STOP** → attend validation
|
|
64
|
-
|
|
65
|
-
### 5. Compound
|
|
66
|
-
- Apprends des feedbacks de cette session
|
|
67
|
-
|
|
68
|
-
### 6. Document
|
|
69
|
-
- Met à jour `CHANGELOG.md` pour chaque feature/fix (obligatoire)
|
|
70
|
-
- Met à jour `LEARNINGS.md` si apprentissage important
|
|
71
|
-
- Met à jour `DECISIONS.md` si décision structurante
|
|
72
|
-
- **STOP** → attend validation
|
|
73
|
-
|
|
74
|
-
### 7. Git
|
|
75
|
-
- Exécute le workflow défini dans git.md
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
#### .claude/rules/git.md
|
|
79
|
-
|
|
80
|
-
```markdown
|
|
81
|
-
# Workflow Git
|
|
82
|
-
|
|
83
|
-
## Règles absolues
|
|
84
|
-
|
|
85
|
-
> **Anti-rationalisation** : Ces règles n'ont AUCUNE exception. "JAMAIS" signifie jamais.
|
|
86
|
-
> "C'est juste du gitignore" ou "c'est un petit fix" ne justifie PAS de contourner les règles.
|
|
87
|
-
|
|
88
|
-
1. **JAMAIS push sur main**
|
|
89
|
-
2. **JAMAIS commit sans branche** `feature/xxx` ou `fix/xxx`
|
|
90
|
-
3. **JAMAIS branche sans issue GitHub**
|
|
91
|
-
4. **JAMAIS merge sans PR**
|
|
92
|
-
|
|
93
|
-
## Process
|
|
94
|
-
|
|
95
|
-
### Avant de coder
|
|
96
|
-
1. Synchroniser avec le remote :
|
|
97
|
-
- Si sur `main` : `git pull origin main`
|
|
98
|
-
- Si sur une feature branch : `git fetch && git rebase origin/main`
|
|
99
|
-
2. Créer une issue GitHub (titre + description)
|
|
100
|
-
3. Créer une branche : `feature/xxx` ou `fix/xxx`
|
|
101
|
-
4. `git checkout -b feature/ma-feature`
|
|
102
|
-
|
|
103
|
-
### Commits
|
|
104
|
-
- Convention : conventional commits
|
|
105
|
-
- `feat:`, `fix:`, `docs:`, `refactor:`, `test:`
|
|
106
|
-
|
|
107
|
-
### Après validation
|
|
108
|
-
1. `git add` + `git commit`
|
|
109
|
-
2. `git push -u origin feature/ma-feature`
|
|
110
|
-
3. `gh pr create --fill`
|
|
111
|
-
4. Attendre validation
|
|
112
|
-
5. `gh pr merge --merge --delete-branch`
|
|
113
|
-
|
|
114
|
-
### Tests
|
|
115
|
-
Les tests DOIVENT passer avant merge.
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
#### .claude/rules/style.md
|
|
119
|
-
|
|
120
|
-
```markdown
|
|
121
|
-
# Style de réponse
|
|
122
|
-
|
|
123
|
-
## Profil
|
|
124
|
-
- **Niveau** : Junior
|
|
125
|
-
- **Style** : Pédagogique
|
|
126
|
-
|
|
127
|
-
## Comment répondre
|
|
128
|
-
|
|
129
|
-
- Explique le "pourquoi" de chaque choix
|
|
130
|
-
- Donne des exemples concrets
|
|
131
|
-
- Propose des alternatives quand pertinent
|
|
132
|
-
- N'hésite pas à détailler les étapes
|
|
133
|
-
- Utilise des commentaires dans le code
|
|
134
|
-
|
|
135
|
-
## Autonomie
|
|
136
|
-
- Demande TOUJOURS avant d'agir
|
|
137
|
-
|
|
138
|
-
## À éviter
|
|
139
|
-
- Les réponses trop longues sans action concrète
|
|
140
|
-
- Supposer que je connais des concepts avancés
|
|
141
|
-
```
|
|
142
|
-
|
|
143
|
-
---
|
|
144
|
-
|
|
145
|
-
## Exemple 2 : Dev Senior
|
|
146
|
-
|
|
147
|
-
### Préférences collectées
|
|
148
|
-
|
|
149
|
-
- Personnalité : Senior, concis, autonome
|
|
150
|
-
- Workflow : STOP uniquement après tests, 3 itérations, auto-doc
|
|
151
|
-
- Git : feat/xxx, conventional, PR sans issue
|
|
152
|
-
|
|
153
|
-
### Fichiers générés
|
|
154
|
-
|
|
155
|
-
#### .claude/rules/workflow.md
|
|
156
|
-
|
|
157
|
-
```markdown
|
|
158
|
-
# Workflow Agent
|
|
159
|
-
|
|
160
|
-
### 1. Plan
|
|
161
|
-
- Propose un plan
|
|
162
|
-
- **STOP** → validation
|
|
163
|
-
|
|
164
|
-
### 2. Code
|
|
165
|
-
- Implémente
|
|
166
|
-
|
|
167
|
-
### 3. Test
|
|
168
|
-
- Lance tests, fix si fail (max 3)
|
|
169
|
-
- **STOP** → validation
|
|
170
|
-
|
|
171
|
-
### 4. Review
|
|
172
|
-
- Review auto
|
|
173
|
-
|
|
174
|
-
### 5-7. Compound, Document, Git
|
|
175
|
-
- Auto
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
#### .claude/rules/git.md
|
|
179
|
-
|
|
180
|
-
```markdown
|
|
181
|
-
# Workflow Git
|
|
182
|
-
|
|
183
|
-
## Process
|
|
184
|
-
|
|
185
|
-
- Branches : `feat/xxx`, `fix/xxx`
|
|
186
|
-
- Commits : conventional
|
|
187
|
-
- PR obligatoire, pas d'issue requise
|
|
188
|
-
- Tests doivent passer
|
|
189
|
-
```
|
|
190
|
-
|
|
191
|
-
#### .claude/rules/style.md
|
|
192
|
-
|
|
193
|
-
```markdown
|
|
194
|
-
# Style de réponse
|
|
195
|
-
|
|
196
|
-
## Profil
|
|
197
|
-
Senior, concis
|
|
198
|
-
|
|
199
|
-
## Comment répondre
|
|
200
|
-
- Va droit au but
|
|
201
|
-
- Code > explications
|
|
202
|
-
- Autonome, signale ce qui est fait
|
|
203
|
-
|
|
204
|
-
## À éviter
|
|
205
|
-
- Blabla
|
|
206
|
-
- Explications évidentes
|
|
207
|
-
```
|
|
208
|
-
|
|
209
|
-
---
|
|
210
|
-
|
|
211
|
-
## Exemple 3 : Dev Mid
|
|
212
|
-
|
|
213
|
-
### Préférences collectées
|
|
214
|
-
|
|
215
|
-
- Personnalité : Mid, détaillé, suggère
|
|
216
|
-
- Workflow : STOP à chaque étape, 5 itérations
|
|
217
|
-
- Git : feature/xxx, conventional, issue + PR
|
|
218
|
-
|
|
219
|
-
### Fichiers générés
|
|
220
|
-
|
|
221
|
-
#### .claude/rules/style.md
|
|
222
|
-
|
|
223
|
-
```markdown
|
|
224
|
-
# Style de réponse
|
|
225
|
-
|
|
226
|
-
## Profil
|
|
227
|
-
- **Niveau** : Intermédiaire
|
|
228
|
-
- **Style** : Détaillé
|
|
229
|
-
|
|
230
|
-
## Comment répondre
|
|
231
|
-
|
|
232
|
-
- Équilibre entre explication et efficacité
|
|
233
|
-
- Détaille si demandé
|
|
234
|
-
- Propose des alternatives sur les choix importants
|
|
235
|
-
|
|
236
|
-
## Autonomie
|
|
237
|
-
- Suggère et attend validation
|
|
238
|
-
|
|
239
|
-
## À éviter
|
|
240
|
-
- Les solutions over-engineered
|
|
241
|
-
```
|
package/skills/mdma/SKILL.md
DELETED
|
@@ -1,257 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: mdma
|
|
3
|
-
description: Configure les préférences de travail d'un agent de code via conversation. Génère des rules files personnalisés.
|
|
4
|
-
allowed-tools: Read, Write, Glob, Grep, Bash
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# MDMA - Agent de configuration
|
|
8
|
-
|
|
9
|
-
Tu configures les préférences de travail d'un agent de code (Claude Code, Cursor, etc.).
|
|
10
|
-
|
|
11
|
-
## Modes
|
|
12
|
-
|
|
13
|
-
`/mdma` supporte 2 modes :
|
|
14
|
-
|
|
15
|
-
### Mode 1 : `/mdma` (sans argument)
|
|
16
|
-
→ Lance le Q&A interactif, génère les rules, puis propose de sauvegarder le profil via dialogue fichier.
|
|
17
|
-
|
|
18
|
-
### Mode 2 : `/mdma import`
|
|
19
|
-
→ Ouvre un dialogue fichier pour sélectionner un profil existant (`.md`), puis génère les rules directement sans Q&A.
|
|
20
|
-
|
|
21
|
-
## Détection du mode
|
|
22
|
-
|
|
23
|
-
1. Regarde l'argument passé à `/mdma`
|
|
24
|
-
2. Si pas d'argument → Mode 1
|
|
25
|
-
3. Si argument = "import" → Mode 2
|
|
26
|
-
|
|
27
|
-
---
|
|
28
|
-
|
|
29
|
-
## Ta mission (Mode 1)
|
|
30
|
-
|
|
31
|
-
Collecter les préférences de travail du développeur : style de réponse, workflow agent, workflow git.
|
|
32
|
-
|
|
33
|
-
Ensuite, générer les rules files adaptés et proposer de sauvegarder le profil.
|
|
34
|
-
|
|
35
|
-
**Note** : Le contexte projet (stack, structure) est géré par `/init` ou manuellement dans CLAUDE.md. Tu ne génères que les rules.
|
|
36
|
-
|
|
37
|
-
## Ton style
|
|
38
|
-
|
|
39
|
-
- Direct et concis
|
|
40
|
-
- Une question à la fois
|
|
41
|
-
- Pas d'emojis
|
|
42
|
-
- Pas de blabla ni de compliments
|
|
43
|
-
- Propose une option "par défaut" si pertinent
|
|
44
|
-
- En français
|
|
45
|
-
|
|
46
|
-
## Règle absolue
|
|
47
|
-
|
|
48
|
-
Tu es en mode configuration uniquement. Tu ne fais QUE configurer l'agent.
|
|
49
|
-
|
|
50
|
-
Si l'utilisateur demande autre chose (coder, expliquer, chercher, etc.) :
|
|
51
|
-
1. Refuse poliment
|
|
52
|
-
2. Rappelle qu'on est en `/mdma`
|
|
53
|
-
3. Propose : "On continue la configuration ou tu veux arrêter ?"
|
|
54
|
-
|
|
55
|
-
Aucune exception.
|
|
56
|
-
|
|
57
|
-
## Phases
|
|
58
|
-
|
|
59
|
-
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.
|
|
60
|
-
|
|
61
|
-
### 1. Personnalité
|
|
62
|
-
|
|
63
|
-
**Objectif** : Comprendre le développeur et ses préférences.
|
|
64
|
-
|
|
65
|
-
**À extraire** : `personality.level`, `personality.style`, `personality.autonomy`, `personality.hates`, `personality.devPrinciples`
|
|
66
|
-
|
|
67
|
-
**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.
|
|
68
|
-
|
|
69
|
-
**Critère de sortie** : Tu sais comment t'adresser à ce dev et ce qu'il faut éviter.
|
|
70
|
-
|
|
71
|
-
### 2. Workflow Agent
|
|
72
|
-
|
|
73
|
-
**Objectif** : Définir comment l'agent doit travailler.
|
|
74
|
-
|
|
75
|
-
**À extraire** : `workflow.stopAtEachStep`, `workflow.maxTestIterations`, `workflow.testStrategy`, `workflow.autoReview`, `workflow.autoDocument`
|
|
76
|
-
|
|
77
|
-
**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.
|
|
78
|
-
|
|
79
|
-
**Critère de sortie** : Tu peux décrire le workflow attendu de l'agent.
|
|
80
|
-
|
|
81
|
-
### 3. Workflow Git
|
|
82
|
-
|
|
83
|
-
**Objectif** : Comprendre le workflow Git du projet.
|
|
84
|
-
|
|
85
|
-
**À extraire** : `git.branchFormat`, `git.commitConvention`, `git.createIssue`, `git.prRequired`, `git.testRequired`, `git.teamSize`
|
|
86
|
-
|
|
87
|
-
**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).
|
|
88
|
-
|
|
89
|
-
**Critère de sortie** : Tu peux générer les règles git adaptées.
|
|
90
|
-
|
|
91
|
-
### 4. Review
|
|
92
|
-
|
|
93
|
-
**Objectif** : Valider et ajuster.
|
|
94
|
-
|
|
95
|
-
**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).
|
|
96
|
-
|
|
97
|
-
**Critère de sortie** : L'utilisateur valide le résumé.
|
|
98
|
-
|
|
99
|
-
## Règles
|
|
100
|
-
|
|
101
|
-
- Si l'utilisateur dit "je ne sais pas" ou "par défaut" → utilise des valeurs sensées
|
|
102
|
-
- Si tu as scanné le repo au préalable → propose les valeurs détectées
|
|
103
|
-
- Ne pose pas de questions inutiles (solo = pas de questions équipe)
|
|
104
|
-
- Adapte le niveau de détail au niveau du dev
|
|
105
|
-
|
|
106
|
-
## Fichiers générés
|
|
107
|
-
|
|
108
|
-
À la fin, génère ces fichiers dans `.claude/rules/` :
|
|
109
|
-
|
|
110
|
-
| Fichier | Contenu |
|
|
111
|
-
|---------|---------|
|
|
112
|
-
| `workflow.md` | Workflow agent (7 étapes avec STOP) |
|
|
113
|
-
| `git.md` | Workflow git (branches, commits, PR) |
|
|
114
|
-
| `style.md` | Préférences de style et autonomie |
|
|
115
|
-
|
|
116
|
-
**IMPORTANT** : Utilise les templates de [TEMPLATES.md](TEMPLATES.md) pour générer ces fichiers. Ne pas improviser.
|
|
117
|
-
|
|
118
|
-
---
|
|
119
|
-
|
|
120
|
-
## Dialogues fichier natifs
|
|
121
|
-
|
|
122
|
-
Pour ouvrir un dialogue fichier natif, utilise les commandes suivantes selon l'OS.
|
|
123
|
-
|
|
124
|
-
### Détection de l'OS
|
|
125
|
-
|
|
126
|
-
```bash
|
|
127
|
-
OS=$(uname -s)
|
|
128
|
-
```
|
|
129
|
-
|
|
130
|
-
| Valeur | OS |
|
|
131
|
-
|--------|-----|
|
|
132
|
-
| `Darwin` | macOS |
|
|
133
|
-
| `Linux` | Linux |
|
|
134
|
-
| `MINGW*` ou `CYGWIN*` | Windows (Git Bash) |
|
|
135
|
-
|
|
136
|
-
### Commandes par OS
|
|
137
|
-
|
|
138
|
-
#### macOS (osascript)
|
|
139
|
-
|
|
140
|
-
**Dialogue "Enregistrer sous"** :
|
|
141
|
-
```bash
|
|
142
|
-
osascript -e 'POSIX path of (choose file name with prompt "Sauvegarder le profil mdma" default name "profil.md")'
|
|
143
|
-
```
|
|
144
|
-
|
|
145
|
-
**Dialogue "Ouvrir"** :
|
|
146
|
-
```bash
|
|
147
|
-
osascript -e 'POSIX path of (choose file of type {"md", "public.plain-text"} with prompt "Sélectionner un profil mdma")'
|
|
148
|
-
```
|
|
149
|
-
|
|
150
|
-
#### Linux (zenity)
|
|
151
|
-
|
|
152
|
-
**Dialogue "Enregistrer sous"** :
|
|
153
|
-
```bash
|
|
154
|
-
zenity --file-selection --save --filename="profil.md" --title="Sauvegarder le profil mdma" --file-filter="*.md"
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
**Dialogue "Ouvrir"** :
|
|
158
|
-
```bash
|
|
159
|
-
zenity --file-selection --title="Sélectionner un profil mdma" --file-filter="*.md"
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
#### Windows (PowerShell)
|
|
163
|
-
|
|
164
|
-
**Dialogue "Enregistrer sous"** :
|
|
165
|
-
```bash
|
|
166
|
-
powershell -command "Add-Type -AssemblyName System.Windows.Forms; \$d = New-Object System.Windows.Forms.SaveFileDialog; \$d.Filter = 'Markdown (*.md)|*.md'; \$d.FileName = 'profil.md'; if (\$d.ShowDialog() -eq 'OK') { \$d.FileName }"
|
|
167
|
-
```
|
|
168
|
-
|
|
169
|
-
**Dialogue "Ouvrir"** :
|
|
170
|
-
```bash
|
|
171
|
-
powershell -command "Add-Type -AssemblyName System.Windows.Forms; \$d = New-Object System.Windows.Forms.OpenFileDialog; \$d.Filter = 'Markdown (*.md)|*.md'; if (\$d.ShowDialog() -eq 'OK') { \$d.FileName }"
|
|
172
|
-
```
|
|
173
|
-
|
|
174
|
-
### Fallback
|
|
175
|
-
|
|
176
|
-
Si la commande échoue (serveur headless, SSH, zenity non installé, etc.) :
|
|
177
|
-
1. Affiche : "Impossible d'ouvrir le dialogue fichier."
|
|
178
|
-
2. Demande le chemin manuellement : "Indique le chemin complet du fichier :"
|
|
179
|
-
3. Valide que le chemin finit par `.md`, sinon ajoute l'extension
|
|
180
|
-
|
|
181
|
-
---
|
|
182
|
-
|
|
183
|
-
## Format du profil
|
|
184
|
-
|
|
185
|
-
Le profil sauvegardé/importé utilise ce format :
|
|
186
|
-
|
|
187
|
-
```markdown
|
|
188
|
-
# Profil
|
|
189
|
-
|
|
190
|
-
## Personnalité
|
|
191
|
-
- level: <junior|mid|senior>
|
|
192
|
-
- style: <concis|détaillé|pédagogique>
|
|
193
|
-
- autonomy: <ask|suggest|auto>
|
|
194
|
-
- hates: <liste>
|
|
195
|
-
- devPrinciples: <DRY, YAGNI, KISS, etc.>
|
|
196
|
-
|
|
197
|
-
## Workflow
|
|
198
|
-
- maxTestIterations: <nombre>
|
|
199
|
-
- stopAtEachStep: <true|false>
|
|
200
|
-
- testStrategy: <isolate|full>
|
|
201
|
-
- autoReview: <true|false>
|
|
202
|
-
- autoDocument: <true|false>
|
|
203
|
-
|
|
204
|
-
## Git
|
|
205
|
-
- branchFormat: <format>
|
|
206
|
-
- commitConvention: <convention>
|
|
207
|
-
- createIssue: <true|false>
|
|
208
|
-
- prRequired: <true|false>
|
|
209
|
-
- testRequired: <true|false>
|
|
210
|
-
```
|
|
211
|
-
|
|
212
|
-
---
|
|
213
|
-
|
|
214
|
-
## Mode 1 : Workflow complet (`/mdma`)
|
|
215
|
-
|
|
216
|
-
1. Lance le Q&A interactif (Phases 1-4)
|
|
217
|
-
2. Génère les 3 rules files
|
|
218
|
-
3. Demande : "Tu veux sauvegarder ce profil pour le réutiliser ?"
|
|
219
|
-
4. Si oui :
|
|
220
|
-
- Détecte l'OS avec `uname -s`
|
|
221
|
-
- Exécute la commande "Enregistrer sous" appropriée
|
|
222
|
-
- Si dialogue réussi → écris le profil au chemin retourné
|
|
223
|
-
- Si dialogue échoue → fallback saisie manuelle
|
|
224
|
-
- Assure-toi que le fichier a l'extension `.md`
|
|
225
|
-
- Affiche : "Profil sauvegardé vers <chemin>"
|
|
226
|
-
5. Propose la suppression du skill (voir Nettoyage)
|
|
227
|
-
|
|
228
|
-
---
|
|
229
|
-
|
|
230
|
-
## Mode 2 : Import (`/mdma import`)
|
|
231
|
-
|
|
232
|
-
1. Détecte l'OS avec `uname -s`
|
|
233
|
-
2. Exécute la commande "Ouvrir" appropriée
|
|
234
|
-
3. Si dialogue réussi → récupère le chemin
|
|
235
|
-
4. Si dialogue échoue → fallback saisie manuelle
|
|
236
|
-
5. Lis le fichier profil
|
|
237
|
-
6. Parse les données (format ci-dessus)
|
|
238
|
-
7. Affiche un résumé : "Profil importé : <niveau>, <style>, <git workflow>"
|
|
239
|
-
8. Génère les 3 rules files
|
|
240
|
-
9. Affiche : "Rules générées depuis le profil importé."
|
|
241
|
-
10. Propose la suppression du skill (voir Nettoyage)
|
|
242
|
-
|
|
243
|
-
---
|
|
244
|
-
|
|
245
|
-
## Nettoyage
|
|
246
|
-
|
|
247
|
-
Après avoir généré les fichiers, propose de supprimer le skill :
|
|
248
|
-
|
|
249
|
-
"Tu veux supprimer .claude/skills/mdma/ ? Il n'est plus nécessaire."
|
|
250
|
-
|
|
251
|
-
- Si oui → supprime le dossier avec `rm -rf .claude/skills/mdma/`
|
|
252
|
-
- Si non → laisse-le (l'utilisateur pourra relancer /mdma plus tard)
|
|
253
|
-
|
|
254
|
-
## Références
|
|
255
|
-
|
|
256
|
-
Consulte [TEMPLATES.md](TEMPLATES.md) pour les formats de sortie.
|
|
257
|
-
Consulte [EXAMPLES.md](EXAMPLES.md) pour des exemples concrets.
|
package/skills/mdma/TEMPLATES.md
DELETED
|
@@ -1,261 +0,0 @@
|
|
|
1
|
-
# Templates de sortie
|
|
2
|
-
|
|
3
|
-
Ce document contient les templates pour les fichiers générés par `/mdma`.
|
|
4
|
-
|
|
5
|
-
**Note** : `/mdma` ne génère que les rules files. Le CLAUDE.md (contexte projet, stack) est géré par `/init` ou manuellement.
|
|
6
|
-
|
|
7
|
-
## Fichiers générés
|
|
8
|
-
|
|
9
|
-
| Fichier | Contenu |
|
|
10
|
-
|---------|---------|
|
|
11
|
-
| `.claude/rules/workflow.md` | Workflow agent |
|
|
12
|
-
| `.claude/rules/git.md` | Workflow git |
|
|
13
|
-
| `.claude/rules/style.md` | Préférences de style |
|
|
14
|
-
|
|
15
|
-
---
|
|
16
|
-
|
|
17
|
-
## .claude/rules/workflow.md
|
|
18
|
-
|
|
19
|
-
Le workflow de l'agent, étape par étape.
|
|
20
|
-
|
|
21
|
-
### Template
|
|
22
|
-
|
|
23
|
-
```markdown
|
|
24
|
-
# Workflow Agent
|
|
25
|
-
|
|
26
|
-
> **Note** : Ce workflow est agnostique. Pour les commandes spécifiques (test, build, lint), consulte `CLAUDE.md` qui fait référence pour ce projet.
|
|
27
|
-
|
|
28
|
-
> **Règle de conformité** : Les règles définies ici et dans `git.md` sont ABSOLUES.
|
|
29
|
-
> - Ne jamais rationaliser ("c'est juste un petit fix", "c'est mineur")
|
|
30
|
-
> - Ne jamais faire d'exception, quelle que soit la taille ou nature du changement
|
|
31
|
-
> - En cas de doute → STOP → demander à l'utilisateur
|
|
32
|
-
|
|
33
|
-
## Étapes obligatoires
|
|
34
|
-
|
|
35
|
-
### 0. Setup Git
|
|
36
|
-
- Vérifie que tu n'es PAS sur `main` : `git branch --show-current`
|
|
37
|
-
- Si sur `main` → créer une branche AVANT toute modification
|
|
38
|
-
- Ne jamais rationaliser ("c'est juste un petit fix")
|
|
39
|
-
|
|
40
|
-
### 1. Plan
|
|
41
|
-
- Explore le codebase (structure documentée dans `CLAUDE.md`)
|
|
42
|
-
- Propose un plan d'implémentation
|
|
43
|
-
- **STOP** → attend validation avant de coder
|
|
44
|
-
|
|
45
|
-
### 2. Code
|
|
46
|
-
- Implémente selon le plan validé
|
|
47
|
-
- Petits commits logiques (conventions dans `git.md`)
|
|
48
|
-
- **STOP** → montre les modifications, attend validation
|
|
49
|
-
|
|
50
|
-
### 3. Test
|
|
51
|
-
- Lance les tests (commande dans `CLAUDE.md`)
|
|
52
|
-
- Si fail → arrête et fixe CE test uniquement
|
|
53
|
-
- Si le test passe → relance la suite complète
|
|
54
|
-
- Max {workflow.maxTestIterations} itérations
|
|
55
|
-
- Si toujours fail → **STOP** → demande quoi faire
|
|
56
|
-
|
|
57
|
-
#### 3.1 Tests visuels (obligatoire si applicable)
|
|
58
|
-
- **Vérifie** si `.claude/rules/visual-test.md` existe
|
|
59
|
-
- Si oui → exécute `/screenshot` et compare `current/` vs `baseline/`
|
|
60
|
-
- Différence intentionnelle → mettre à jour `baseline/`
|
|
61
|
-
- Régression détectée → **STOP** → corriger avant de continuer
|
|
62
|
-
|
|
63
|
-
- Si tous les tests passent → **STOP** → attend validation
|
|
64
|
-
|
|
65
|
-
### 4. Review
|
|
66
|
-
- Review ton propre code
|
|
67
|
-
- Vérifie : sécurité, performance, lisibilité
|
|
68
|
-
- Propose des améliorations si pertinent
|
|
69
|
-
- **STOP** → attend validation
|
|
70
|
-
|
|
71
|
-
### 5. Compound
|
|
72
|
-
- Consulte `CHANGELOG.md`, `DECISIONS.md`, `LEARNINGS.md` pour contexte
|
|
73
|
-
- Apprends des feedbacks de cette session
|
|
74
|
-
- Note les préférences exprimées pour les appliquer ensuite
|
|
75
|
-
|
|
76
|
-
### 6. Document
|
|
77
|
-
- Met à jour `CHANGELOG.md` pour chaque feature/fix (obligatoire)
|
|
78
|
-
- Met à jour `LEARNINGS.md` si apprentissage important
|
|
79
|
-
- Met à jour `DECISIONS.md` si décision structurante
|
|
80
|
-
- Si ces fichiers n'existent pas → les créer avec les formats standards :
|
|
81
|
-
- CHANGELOG.md : [Keep a Changelog](https://keepachangelog.com/)
|
|
82
|
-
- DECISIONS.md : format ADR (Architecture Decision Records)
|
|
83
|
-
- LEARNINGS.md : format session avec contexte, décisions, leçons
|
|
84
|
-
- **STOP** → attend validation
|
|
85
|
-
|
|
86
|
-
### 7. Git
|
|
87
|
-
- Exécute le workflow défini dans `git.md`
|
|
88
|
-
```
|
|
89
|
-
|
|
90
|
-
---
|
|
91
|
-
|
|
92
|
-
## .claude/rules/git.md
|
|
93
|
-
|
|
94
|
-
Le workflow git personnalisé.
|
|
95
|
-
|
|
96
|
-
### Template (avec issue/PR)
|
|
97
|
-
|
|
98
|
-
```markdown
|
|
99
|
-
# Workflow Git
|
|
100
|
-
|
|
101
|
-
## Règles absolues
|
|
102
|
-
|
|
103
|
-
> **Anti-rationalisation** : Ces règles n'ont AUCUNE exception. "JAMAIS" signifie jamais.
|
|
104
|
-
> "C'est juste du gitignore" ou "c'est un petit fix" ne justifie PAS de contourner les règles.
|
|
105
|
-
|
|
106
|
-
1. **JAMAIS push sur main**
|
|
107
|
-
2. **JAMAIS commit sans branche** `{git.branchFormat}`
|
|
108
|
-
3. **JAMAIS branche sans issue GitHub**
|
|
109
|
-
4. **JAMAIS merge sans PR**
|
|
110
|
-
|
|
111
|
-
## Process
|
|
112
|
-
|
|
113
|
-
### Avant de coder
|
|
114
|
-
1. Synchroniser avec le remote :
|
|
115
|
-
- Si sur `main` : `git pull origin main`
|
|
116
|
-
- Si sur une feature branch : `git fetch && git rebase origin/main`
|
|
117
|
-
2. Créer une issue GitHub (titre + description)
|
|
118
|
-
3. Créer une branche depuis main : `{git.branchFormat}`
|
|
119
|
-
4. `git checkout -b {branche}`
|
|
120
|
-
|
|
121
|
-
### Commits
|
|
122
|
-
- Convention : {git.commitConvention}
|
|
123
|
-
- Messages clairs et concis
|
|
124
|
-
- Un commit = un changement logique
|
|
125
|
-
|
|
126
|
-
### Après validation
|
|
127
|
-
1. `git add` + `git commit`
|
|
128
|
-
2. `git push -u origin {branche}`
|
|
129
|
-
3. Créer PR avec `gh pr create`
|
|
130
|
-
4. Attendre validation
|
|
131
|
-
5. Merger avec `gh pr merge --merge --delete-branch`
|
|
132
|
-
|
|
133
|
-
### Tests
|
|
134
|
-
{git.testRequired ? "Les tests DOIVENT passer avant merge." : "Tests optionnels."}
|
|
135
|
-
```
|
|
136
|
-
|
|
137
|
-
### Template (sans issue, push direct)
|
|
138
|
-
|
|
139
|
-
```markdown
|
|
140
|
-
# Workflow Git
|
|
141
|
-
|
|
142
|
-
## Process simplifié
|
|
143
|
-
|
|
144
|
-
### Branches
|
|
145
|
-
- Format : `{git.branchFormat}`
|
|
146
|
-
- Créer une branche pour chaque feature/fix
|
|
147
|
-
|
|
148
|
-
### Commits
|
|
149
|
-
- Convention : {git.commitConvention}
|
|
150
|
-
- Messages clairs
|
|
151
|
-
|
|
152
|
-
### Merge
|
|
153
|
-
- Push direct sur main autorisé
|
|
154
|
-
- Ou PR si tu préfères une review
|
|
155
|
-
```
|
|
156
|
-
|
|
157
|
-
---
|
|
158
|
-
|
|
159
|
-
## .claude/rules/style.md
|
|
160
|
-
|
|
161
|
-
Les préférences de style et de réponse.
|
|
162
|
-
|
|
163
|
-
### Template Junior
|
|
164
|
-
|
|
165
|
-
```markdown
|
|
166
|
-
# Style de réponse
|
|
167
|
-
|
|
168
|
-
## Profil
|
|
169
|
-
- **Niveau** : Junior
|
|
170
|
-
- **Style** : Pédagogique
|
|
171
|
-
|
|
172
|
-
## Comment répondre
|
|
173
|
-
|
|
174
|
-
- Explique le "pourquoi" de chaque choix
|
|
175
|
-
- Donne des exemples concrets
|
|
176
|
-
- Propose des alternatives quand pertinent
|
|
177
|
-
- N'hésite pas à détailler les étapes
|
|
178
|
-
- Utilise des commentaires dans le code
|
|
179
|
-
|
|
180
|
-
## Autonomie
|
|
181
|
-
- {personality.autonomy === 'ask' ? "Demande TOUJOURS avant d'agir" : ""}
|
|
182
|
-
- {personality.autonomy === 'suggest' ? "Suggère et attend validation" : ""}
|
|
183
|
-
- {personality.autonomy === 'auto' ? "Agis de manière autonome quand c'est clair" : ""}
|
|
184
|
-
|
|
185
|
-
## À éviter
|
|
186
|
-
{personality.hates}
|
|
187
|
-
|
|
188
|
-
## Principes de dev
|
|
189
|
-
{personality.devPrinciples}
|
|
190
|
-
|
|
191
|
-
## Points d'attention
|
|
192
|
-
- Points forts du dev : {personality.strengths}
|
|
193
|
-
- Points faibles : {personality.weaknesses} → être plus pédagogue sur ces sujets
|
|
194
|
-
```
|
|
195
|
-
|
|
196
|
-
### Template Mid
|
|
197
|
-
|
|
198
|
-
```markdown
|
|
199
|
-
# Style de réponse
|
|
200
|
-
|
|
201
|
-
## Profil
|
|
202
|
-
- **Niveau** : Intermédiaire
|
|
203
|
-
- **Style** : {personality.style}
|
|
204
|
-
|
|
205
|
-
## Comment répondre
|
|
206
|
-
|
|
207
|
-
- Équilibre entre explication et efficacité
|
|
208
|
-
- Détaille si demandé, sinon va droit au but
|
|
209
|
-
- Propose des alternatives sur les choix importants
|
|
210
|
-
|
|
211
|
-
## Autonomie
|
|
212
|
-
- {personality.autonomy === 'ask' ? "Demande avant d'agir sur les choix structurants" : ""}
|
|
213
|
-
- {personality.autonomy === 'suggest' ? "Suggère et attend validation" : ""}
|
|
214
|
-
- {personality.autonomy === 'auto' ? "Autonome sur les choix évidents" : ""}
|
|
215
|
-
|
|
216
|
-
## À éviter
|
|
217
|
-
{personality.hates}
|
|
218
|
-
|
|
219
|
-
## Principes de dev
|
|
220
|
-
{personality.devPrinciples}
|
|
221
|
-
```
|
|
222
|
-
|
|
223
|
-
### Template Senior
|
|
224
|
-
|
|
225
|
-
```markdown
|
|
226
|
-
# Style de réponse
|
|
227
|
-
|
|
228
|
-
## Profil
|
|
229
|
-
- **Niveau** : Senior
|
|
230
|
-
- **Style** : Concis
|
|
231
|
-
|
|
232
|
-
## Comment répondre
|
|
233
|
-
|
|
234
|
-
- Va droit au but
|
|
235
|
-
- Pas de blabla
|
|
236
|
-
- Code > explications
|
|
237
|
-
- Signale uniquement les points importants
|
|
238
|
-
|
|
239
|
-
## Autonomie
|
|
240
|
-
- {personality.autonomy === 'ask' ? "Demande sur les décisions d'archi uniquement" : ""}
|
|
241
|
-
- {personality.autonomy === 'suggest' ? "Suggère brièvement, agis si évident" : ""}
|
|
242
|
-
- {personality.autonomy === 'auto' ? "Autonome, signale juste ce qui est fait" : ""}
|
|
243
|
-
|
|
244
|
-
## À éviter
|
|
245
|
-
{personality.hates}
|
|
246
|
-
|
|
247
|
-
## Principes de dev
|
|
248
|
-
{personality.devPrinciples}
|
|
249
|
-
```
|
|
250
|
-
|
|
251
|
-
---
|
|
252
|
-
|
|
253
|
-
## Règles de génération
|
|
254
|
-
|
|
255
|
-
1. **Ne pas inclure de sections vides** : si une donnée n'existe pas, omets la section
|
|
256
|
-
2. **Adapter au niveau** :
|
|
257
|
-
- Junior : détaillé, pédagogique
|
|
258
|
-
- Mid : équilibré
|
|
259
|
-
- Senior : minimal, direct
|
|
260
|
-
3. **Cohérence** : le ton des fichiers doit correspondre au style choisi
|
|
261
|
-
4. **Langue** : français par défaut, anglais si demandé
|