Comment ranger les fichiers mini-me d'un projet dans un dossier .mm

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

# Comment ranger les fichiers mini-me d'un projet dans un dossier `.mm`

Ce guide montre comment mettre la configuration d'un agent, ses skills, ses hooks et ses sessions dans un dossier `.mm` à la racine d'un projet, plutôt qu'à côté de ses sources, tout en lançant l'agent par un simple `mm` ou `mm tui`. Il suppose que `mm` est installé dans votre `PATH` et que vous avez déjà un `agent.yaml` (écrit par `mm init`, par exemple).

## Étapes

1. Créez le dossier et déplacez-y la configuration :

   ```bash
   mkdir -p .mm
   mv agent.yaml .mm/agent.yaml
   ```

2. Écrivez chaque chemin relatif de `.mm/agent.yaml` **depuis la racine du projet**, pas depuis `.mm/` :

   ```yaml
   skillsDir: .mm/skills
   sessions:
     enabled: true
     dir: .mm/sessions
   hooks:
     preToolCall:
       - matcher: ^bash$
         command: node "$MM_CONFIG_DIR/.mm/hooks/bash-guard.js"
   ```

   Pour un fichier dans un dossier `.mm`, `$MM_CONFIG_DIR` est la racine du projet : un script de hook rangé dans `.mm/hooks/` s'écrit donc `$MM_CONFIG_DIR/.mm/hooks/…`. Il en va de même pour `mmConfigs`, les deciders de `skillRouting` et de `toolRouting`, et `tools[].wasm`.

3. Lancez l'agent depuis la racine du projet, sans argument :

   ```bash
   mm        # ou : mm tui
   ```

   La bannière indique le fichier lu :

   ```
   mm … | config: .mm/agent.yaml | provider: …
   ```

## Variantes

- **Un nouvel agent.** `mm init` fait tout cela si vous répondez `yes` à sa première question, ou avec `mm init --project yes` : il crée `.mm/`, écrit `.mm/agent.yaml` avec des chemins depuis la racine du projet et, avec `--skills yes`, crée `.mm/skills/`. Voir [Comment créer un agent avec `mm init`](create-an-agent.md).

- **Un `agent.yaml` se trouve aussi à la racine.** C'est lui qui l'emporte : `mm` lit d'abord `./agent.yaml`, et `./.mm/agent.yaml` seulement s'il n'y en a pas. Supprimez ou renommez le fichier de la racine, ou nommez celui que vous voulez : `mm -config .mm/agent.yaml`.
- **Dans un Docker Sandbox.** `mm sbxinit` trouve `.mm/agent.yaml` et écrit un `sbxenv.yaml` qui monte `.mm/` en lecture seule, ses sessions et ses traces en écriture ; voir [Quand l'agent est dans un dossier `.mm`](run-in-a-docker-sandbox.md#quand-lagent-est-dans-un-dossier-mm).
- **Depuis un éditeur (ACP).** Donnez à `AGENT_CONFIG` le chemin absolu de `.mm/agent.yaml`. Ses chemins gardent le même sens : un `skillsDir` relatif comme `.mm/skills` est résolu depuis la racine du projet, pas depuis le répertoire de travail de l'éditeur. Voir [Comment utiliser mini-me depuis un éditeur](use-from-an-editor.md).
- **Lancé depuis un sous-dossier.** La recherche ne regarde que le répertoire de travail : depuis `src/`, `mm` ne trouve pas `../.mm/agent.yaml`. Lancez-le depuis la racine : dans un terminal, un `skillsDir` relatif suit le répertoire de travail, donc `mm -config ../.mm/agent.yaml` lancé depuis `src/` chercherait les skills dans `src/.mm/skills`.
- **Plusieurs agents dans un projet.** Rangez les autres dans le même dossier (`.mm/agents/reviewer.yaml`) et nommez-les avec `-config`, ou depuis `mmConfigs` (`reviewer: .mm/agents/reviewer.yaml`). Seul un fichier placé *directement* dans `.mm` prend la racine du projet comme base : les chemins de `.mm/agents/reviewer.yaml` sont relatifs à `.mm/agents/`.

## Prérequis

`mm` v1.0.7 ou plus récent. Un `mm` plus ancien ne cherche pas dans `.mm/`, et résout les chemins d'un `.mm/agent.yaml` depuis `.mm/` lui-même : `$MM_CONFIG_DIR/.mm/hooks/…` désigne alors `.mm/.mm/hooks/…`.

Quand le même agent peut tourner avec les deux — un kit Docker Sandbox embarque souvent un mm plus ancien que celui de votre machine —, écrivez les commandes des hooks avec `${MM_CONFIG_DIR%/.mm}`, qui retire un `/.mm` final et donne la racine du projet avec n'importe quel mm (les commandes de hooks tournent dans `sh -c`) :

```yaml
hooks:
  preToolCall:
    - matcher: ^bash$
      command: node "${MM_CONFIG_DIR%/.mm}/.mm/hooks/bash-guard.js"
```

Un script qui construit lui-même des chemins à partir de `MM_CONFIG_DIR` suit la même règle : prendre le dossier parent quand le dernier élément est `.mm`.

## Voir aussi

- L'ordre de recherche et la règle du répertoire de base : [Résolution du fichier de configuration](../reference/cli.md#résolution-du-fichier-de-configuration)
- Toutes les clés du fichier : [Référence de la configuration](../reference/configuration.md)
- Les variables reçues par un hook : [Référence des hooks](../reference/hooks.md)