bots-garden/mini-me · #25

added .tickets/issues/0079-auto-update-of-the-system-instructions-and-skill.yaml +13 -0 Viewed

new file mode 100644
@@ -0,0 +1,13 @@
	1	+# Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
	2	+id: 79
	3	+title: Auto update of the system instructions and skills
	4	+state: open
	5	+author:
	6	+ name: k33g
	7	+ email: ph.charriere@gmail.com
	8	+createdAt: 2026-10-07T09:00:46.595Z
	9	+updatedAt: 2026-10-07T09:00:46.595Z
	10	+labels: []
	11	+body: ""
	12	+tasks: []
	13	+comments: []

++# Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
++id: 79
++title: Auto update of the system instructions and skills
++state: open
++author:
++  name: k33g
++  email: ph.charriere@gmail.com
++createdAt: 2026-10-07T09:00:46.595Z
++updatedAt: 2026-10-07T09:00:46.595Z
++labels: []
++body: ""
++tasks: []
++comments: []

modified .vscode/settings.json +1 -1 Viewed

@@ -2,7 +2,7 @@
2	2	"workbench.iconTheme": "material-icon-theme",
3	3	"workbench.colorTheme": "GitHub Light Colorblind (Beta)",
4	4	"editor.fontSize": 14,
5		- "terminal.integrated.fontSize": 14,
	5	+ "terminal.integrated.fontSize": 16,
6	6	"editor.insertSpaces": true,
7	7	"editor.tabSize": 4,
8	8	"editor.detectIndentation": true,

    "workbench.iconTheme": "material-icon-theme",
    "workbench.colorTheme": "GitHub Light Colorblind (Beta)",
    "editor.fontSize": 14,
--  "terminal.integrated.fontSize": 14,
++  "terminal.integrated.fontSize": 16,
    "editor.insertSpaces": true,
    "editor.tabSize": 4,
    "editor.detectIndentation": true,

modified demo-llmman/README.en.md +35 -33 Viewed

@@ -6,22 +6,26 @@ This folder shows how one mini-me agent (Bob) can put questions to other mini-me
6	6
7	7	\| File \| Role \|
8	8	\|---\|---\|
9		-\| `agent.llmman.yaml` \| Bob, the agent you start (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Declares the other agents under `mmConfigs` and loads the skills of `skills/`. \|
	9	+\| `agent.llmman.yaml` \| Bob, the agent you start (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Declares the other agents under `mmConfigs`, with a description and, for Lucy, her own `yolo`. \|
10	10	\| `agent.jan-nano.yaml` \| Jan (`hf.co/Menlo/Jan-nano-gguf:Q4_K_M`), a full agent with its tools. \|
11	11	\| `agent.lucy.yaml` \| Lucy (`hf.co/Menlo/Lucy-gguf:Q4_K_M`), a full agent with its tools. \|
12	12	\| `agent.lucy-reviewer.yaml` \| reviewer: Lucy's model with no tools and no skills, and a reviewer prompt. It only answers. \|
13		-\| `skills/delegate-to-jan` \| Skill: delegate a question to Jan. \|
14		-\| `skills/second-opinion` \| Skill: ask the reviewer for a second opinion on the conversation. \|
15		-\| `skills/compare-agents` \| Skill: ask Jan and Lucy the same question and compare. \|
16	13	\| `skills/bg-jobs` \| Copy of the general skill (Bob's prompt refers to it). \|
17	14
18	15	In `agent.llmman.yaml`:
19	16
20	17	```yaml
21	18	mmConfigs:
22		- jan: agent.jan-nano.yaml
23		- lucy: agent.lucy.yaml
24		- reviewer: agent.lucy-reviewer.yaml
	19	+ jan:
	20	+ path: agent.jan-nano.yaml
	21	+ description: Research and fact questions — looks things up and answers in a few lines.
	22	+ lucy:
	23	+ path: agent.lucy.yaml
	24	+ description: A coding agent — reads, writes and runs code in this project. …
	25	+ yolo: true
	26	+ reviewer:
	27	+ path: agent.lucy-reviewer.yaml
	28	+ description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
25	29	```
26	30
27	31	## Prerequisites
@@ -86,58 +90,56 @@ printf 'User: My name is Philippe and I like Go.\nAssistant: Nice to meet you, P
86	90	- The question comes from `-p`, or else from stdin. For `--ask-with-context`, stdin is the context; without `-p`, the context, a `---` line, then the question.
87	91	- stdout holds the answer only (`answer=$(../mm agent.llmman.yaml --ask jan -p "…")` works); the label, the tool calls and errors go to stderr.
88	92	- Exit codes: `0` answered, `1` failed (reason on stderr, e.g. `[ask: unknown agent "spock" — agents in this config: jan, lucy, reviewer]`), `130` interrupted.
89		-- The asked agent's tools are allowed in this mode. For an agent that should only answer, use `reviewer`.
	93	+- The asked agent's tool calls follow its `mmConfigs` entry's `yolo` (Lucy: `true`, they run), else `agent.llmman.yaml`'s (`false`: rejected, nobody can answer). For an agent that should only answer, use `reviewer`.
90	94
91		-## 3. Let Bob ask the others through his skills
	95	+## 3. Let Bob decide: the `ask_agent` tool
92	96
93		-Bob exports `MM_BIN` (his own binary) and `MM_CONFIG` (his configuration) to the commands his bash tool runs. The skills therefore just call `"$MM_BIN" --ask …`, without knowing any path. Ask in plain words:
	97	+Since `mmConfigs` is not empty, Bob has the built-in `ask_agent` tool. Its description lists Jan, Lucy and the reviewer with their `description`: Bob chooses, no skill involved. Ask in plain words:
94	98
95		-\| You say \| Skill \| Command Bob runs \|
96		-\|---\|---\|---\|
97		-\| "Ask Jan what the capital of Peru is." \| `delegate-to-jan` \| `"$MM_BIN" --ask jan -p "What is the capital of Peru?"` \|
98		-\| "I think Go's goroutines are OS threads. Get a second opinion from Lucy on that claim." \| `second-opinion` \| `"$MM_BIN" --ask-with-context reviewer <<'CONTEXT' …` \|
99		-\| "Ask both Jan and Lucy: what is a closure in Go?" \| `compare-agents` \| both `--ask` in one command \|
	99	+\| You say \| Bob calls \|
	100	+\|---\|---\|
	101	+\| "Ask Jan what the capital of Peru is." \| `ask_agent` → `jan` \|
	102	+\| "I think Go's goroutines are OS threads. Get a second opinion on that claim." \| `ask_agent` → `reviewer`, with `with_context` \|
	103	+\| "Ask Lucy to add a test for main.go and run it." \| `ask_agent` → `lucy`, whose writes and commands run without asking (`yolo: true` in her entry) \|
100	104
101		-A real run (`second-opinion`, 97 s in all):
	105	+Bob has `yolo: false`: you approve each hand-off first, with the prompt he wrote. In the window (`../mm -tui agent.llmman.yaml`), the asked agent is named while it works:
102	106
103	107	```text
104		-📖 read_skill: second-opinion
105		-🛠️ bash: "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
106		-User: I think Go's goroutines are OS threads.
107		-Assistant: Actually, Go goroutines are not OS threads. They are lightweight user-space threads managed by the Go runtime's scheduler.
108		----
109		-Is Go's goroutine implementation OS threads?
110		-CONTEXT
111		- │ 🗣 asking reviewer (llmman/hf.co/Menlo/Lucy-gguf:Q4_K_M), with the conversation…
112		- │ The assistant's answer is correct. Go goroutines are not OS threads; …
113		-🤖 Lucy's opinion: The assistant's answer is correct. … I agree with Lucy.
	108	+mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
	109	+…
	110	+‣ mm [Jan (coding agent)]
	111	+The capital of Peru is Lima.
114	112	```
115	113
116		-`compare-agents` has not been tried live yet.
	114	+then the header comes back to Bob, who concludes under `‣ mm [Bob (coordinator)]`. Measured: 6 s for Jan, 5.6 s for the reviewer (`mm -p`, models already loaded).
	115	+
	116	+The answer comes back to Bob as the tool's result, in the same turn; it is not added to the history as with `/ask`.
117	117
118	118	## Time settings
119	119
120	120	A small local model can take a minute to answer, so `agent.llmman.yaml` raises two limits:
121	121
122	122	```yaml
123		-watchdogTimeout: 3m # the watchdog keeps counting while a command runs (ticket 57)
124		-bashTimeout: 3m # how long one bash command may run (default 30s)
	123	+watchdogTimeout: 3m # silence tolerated; during ask_agent each event of the asked agent counts as a sign of life
	124	+bashTimeout: 3m # how long one bash command may run (default 30s), for a script running mm --ask
125	125	```
126	126
127		-With the defaults, a skill that asks an agent ends in `[error: 30s timeout exceeded]` or `connection hang detected after 30s`.
	127	+With `ask_agent`, only a long silence of the asked agent (its model loading, a long first prompt being read) can still exceed `watchdogTimeout`.
128	128
129	129	## Good to know
130	130
131		-- Small models, every tool: Lucy (1.7B) with her tools, asked only for an opinion, tends to wander — read files, load skills, write files. Hence the tool-less `reviewer` profile for `second-opinion`.
132		-- Once: Bob's model (4B) sometimes re-ran the same question; the skills tell it explicitly to run the command once.
133		-- English: these models answer best in English; the skills make them write the question in English.
	131	+- Small models, every tool: Lucy (1.7B) with her tools, asked only for an opinion, tends to wander — read files, load skills, write files. Hence the tool-less `reviewer` profile for second opinions.
	132	+- Once: Bob's model (4B) sometimes re-ran the same question; his prompt tells him to call `ask_agent` once per task.
	133	+- English: these models answer best in English.
134	134	- No sessions for the asked agents: they run with `AGENT_SESSIONS=off`, so your `/sessions` lists Bob's only.
135	135	- Limited depth: Bob may ask Jan, Jan may ask another agent, but that one cannot ask anybody (`MM_ASK_DEPTH`).
136	136	- Names: a skill must not be named like a generated command (`ask-jan`…); mm warns at start-up.
	137	+- The delegation skills (`delegate-to-jan`, `second-opinion`, `compare-agents`) that had Bob run `mm --ask` were removed in favour of `ask_agent`; they remain in the git history (commit 8941766), and the skills guide shows one.
137	138
138	139	## Going further
139	140
140	141	- [How to ask another mm agent from your session](../docs/en/how-to/ask-another-agent.md)
	142	+- [How to let your agent call other agents](../docs/en/how-to/let-the-agent-call-other-agents.md)
141	143	- [How to ask another agent from a skill or a script](../docs/en/how-to/ask-another-agent-from-a-skill.md)
142	144	- [Slash commands reference](../docs/en/reference/slash-commands.md#asking-another-agent) · [Command-line reference](../docs/en/reference/cli.md#ask-mode-specifics)
143	145	- [Why it is built this way](../docs/en/explanation/asking-another-agent.md)

  | File | Role |
  |---|---|
--| `agent.llmman.yaml` | **Bob**, the agent you start (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Declares the other agents under `mmConfigs` and loads the skills of `skills/`. |
++| `agent.llmman.yaml` | **Bob**, the agent you start (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Declares the other agents under `mmConfigs`, with a description and, for Lucy, her own `yolo`. |
  | `agent.jan-nano.yaml` | **Jan** (`hf.co/Menlo/Jan-nano-gguf:Q4_K_M`), a full agent with its tools. |
  | `agent.lucy.yaml` | **Lucy** (`hf.co/Menlo/Lucy-gguf:Q4_K_M`), a full agent with its tools. |
  | `agent.lucy-reviewer.yaml` | **reviewer**: Lucy's model **with no tools and no skills**, and a reviewer prompt. It only answers. |
--| `skills/delegate-to-jan` | Skill: delegate a question to Jan. |
--| `skills/second-opinion` | Skill: ask the reviewer for a second opinion on the conversation. |
--| `skills/compare-agents` | Skill: ask Jan and Lucy the same question and compare. |
  | `skills/bg-jobs` | Copy of the general skill (Bob's prompt refers to it). |
  In `agent.llmman.yaml`:
  ```yaml
  mmConfigs:
--  jan: agent.jan-nano.yaml
++  jan:
--  lucy: agent.lucy.yaml
++    path: agent.jan-nano.yaml
--  reviewer: agent.lucy-reviewer.yaml
++    description: Research and fact questions — looks things up and answers in a few lines.
++  lucy:
++    path: agent.lucy.yaml
++    description: A coding agent — reads, writes and runs code in this project. …
++    yolo: true
++  reviewer:
++    path: agent.lucy-reviewer.yaml
++    description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
  ```
  ## Prerequisites
  - The question comes from `-p`, or else from stdin. For `--ask-with-context`, stdin is the context; without `-p`, the context, a `---` line, then the question.
  - **stdout holds the answer only** (`answer=$(../mm agent.llmman.yaml --ask jan -p "…")` works); the label, the tool calls and errors go to stderr.
  - Exit codes: `0` answered, `1` failed (reason on stderr, e.g. `[ask: unknown agent "spock" — agents in this config: jan, lucy, reviewer]`), `130` interrupted.
--- The asked agent's tools are **allowed** in this mode. For an agent that should only answer, use `reviewer`.
++- The asked agent's tool calls follow its `mmConfigs` entry's `yolo` (Lucy: `true`, they run), else `agent.llmman.yaml`'s (`false`: rejected, nobody can answer). For an agent that should only answer, use `reviewer`.
--## 3. Let Bob ask the others through his skills
++## 3. Let Bob decide: the `ask_agent` tool
--Bob exports `MM_BIN` (his own binary) and `MM_CONFIG` (his configuration) to the commands his bash tool runs. The skills therefore just call `"$MM_BIN" --ask …`, without knowing any path. Ask in plain words:
++Since `mmConfigs` is not empty, Bob has the built-in `ask_agent` tool. Its description lists Jan, Lucy and the reviewer with their `description`: Bob chooses, no skill involved. Ask in plain words:
--| You say | Skill | Command Bob runs |
++| You say | Bob calls |
--|---|---|---|
++|---|---|
--| "Ask Jan what the capital of Peru is." | `delegate-to-jan` | `"$MM_BIN" --ask jan -p "What is the capital of Peru?"` |
++| "Ask Jan what the capital of Peru is." | `ask_agent` → `jan` |
--| "I think Go's goroutines are OS threads. Get a second opinion from Lucy on that claim." | `second-opinion` | `"$MM_BIN" --ask-with-context reviewer <<'CONTEXT' …` |
++| "I think Go's goroutines are OS threads. Get a second opinion on that claim." | `ask_agent` → `reviewer`, with `with_context` |
--| "Ask both Jan and Lucy: what is a closure in Go?" | `compare-agents` | both `--ask` in one command |
++| "Ask Lucy to add a test for main.go and run it." | `ask_agent` → `lucy`, whose writes and commands run without asking (`yolo: true` in her entry) |
--A real run (`second-opinion`, 97 s in all):
++Bob has `yolo: false`: you approve each hand-off first, with the prompt he wrote. In the window (`../mm -tui agent.llmman.yaml`), the asked agent is named while it works:
  ```text
--📖 read_skill: second-opinion
++mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
--🛠️  bash: "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
++…
--User: I think Go's goroutines are OS threads.
++‣ mm [Jan (coding agent)]
--Assistant: Actually, Go goroutines are not OS threads. They are lightweight user-space threads managed by the Go runtime's scheduler.
++The capital of Peru is Lima.
-----
--Is Go's goroutine implementation OS threads?
--CONTEXT
--   │ 🗣 asking reviewer (llmman/hf.co/Menlo/Lucy-gguf:Q4_K_M), with the conversation…
--   │ The assistant's answer is correct. Go goroutines are not OS threads; …
--🤖 Lucy's opinion: The assistant's answer is correct. … I agree with Lucy.
  ```
--`compare-agents` has not been tried live yet.
++then the header comes back to Bob, who concludes under `‣ mm [Bob (coordinator)]`. Measured: 6 s for Jan, 5.6 s for the reviewer (`mm -p`, models already loaded).
++
++The answer comes back to Bob as the tool's result, in the same turn; it is not added to the history as with `/ask`.
  ## Time settings
  A small local model can take a minute to answer, so `agent.llmman.yaml` raises two limits:
  ```yaml
--watchdogTimeout: 3m   # the watchdog keeps counting while a command runs (ticket 57)
++watchdogTimeout: 3m   # silence tolerated; during ask_agent each event of the asked agent counts as a sign of life
--bashTimeout: 3m       # how long one bash command may run (default 30s)
++bashTimeout: 3m       # how long one bash command may run (default 30s), for a script running mm --ask
  ```
--With the defaults, a skill that asks an agent ends in `[error: 30s timeout exceeded]` or `connection hang detected after 30s`.
++With `ask_agent`, only a long silence of the asked agent (its model loading, a long first prompt being read) can still exceed `watchdogTimeout`.
  ## Good to know
--- **Small models, every tool**: Lucy (1.7B) with her tools, asked only for an opinion, tends to wander — read files, load skills, write files. Hence the tool-less `reviewer` profile for `second-opinion`.
++- **Small models, every tool**: Lucy (1.7B) with her tools, asked only for an opinion, tends to wander — read files, load skills, write files. Hence the tool-less `reviewer` profile for second opinions.
--- **Once**: Bob's model (4B) sometimes re-ran the same question; the skills tell it explicitly to run the command once.
++- **Once**: Bob's model (4B) sometimes re-ran the same question; his prompt tells him to call `ask_agent` once per task.
--- **English**: these models answer best in English; the skills make them write the question in English.
++- **English**: these models answer best in English.
  - **No sessions for the asked agents**: they run with `AGENT_SESSIONS=off`, so your `/sessions` lists Bob's only.
  - **Limited depth**: Bob may ask Jan, Jan may ask another agent, but that one cannot ask anybody (`MM_ASK_DEPTH`).
  - **Names**: a skill must not be named like a generated command (`ask-jan`…); mm warns at start-up.
++- **The delegation skills** (`delegate-to-jan`, `second-opinion`, `compare-agents`) that had Bob run `mm --ask` were removed in favour of `ask_agent`; they remain in the git history (commit 8941766), and the skills guide shows one.
  ## Going further
  - [How to ask another mm agent from your session](../docs/en/how-to/ask-another-agent.md)
++- [How to let your agent call other agents](../docs/en/how-to/let-the-agent-call-other-agents.md)
  - [How to ask another agent from a skill or a script](../docs/en/how-to/ask-another-agent-from-a-skill.md)
  - [Slash commands reference](../docs/en/reference/slash-commands.md#asking-another-agent) · [Command-line reference](../docs/en/reference/cli.md#ask-mode-specifics)
  - [Why it is built this way](../docs/en/explanation/asking-another-agent.md)

modified demo-llmman/README.md +35 -33 Viewed

@@ -6,22 +6,26 @@ Ce dossier montre comment un agent mini-me (Bob) peut poser des questions à d'a
6	6
7	7	\| Fichier \| Rôle \|
8	8	\|---\|---\|
9		-\| `agent.llmman.yaml` \| Bob, l'agent que vous lancez (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Déclare les autres agents sous `mmConfigs` et charge les skills de `skills/`. \|
	9	+\| `agent.llmman.yaml` \| Bob, l'agent que vous lancez (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Déclare les autres agents sous `mmConfigs`, avec une description et, pour Lucy, son propre `yolo`. \|
10	10	\| `agent.jan-nano.yaml` \| Jan (`hf.co/Menlo/Jan-nano-gguf:Q4_K_M`), agent complet avec ses outils. \|
11	11	\| `agent.lucy.yaml` \| Lucy (`hf.co/Menlo/Lucy-gguf:Q4_K_M`), agent complet avec ses outils. \|
12	12	\| `agent.lucy-reviewer.yaml` \| reviewer : le modèle de Lucy sans outils ni skills, avec un prompt de relecteur. Il ne fait que répondre. \|
13		-\| `skills/delegate-to-jan` \| Skill : déléguer une question à Jan. \|
14		-\| `skills/second-opinion` \| Skill : demander au relecteur un deuxième avis sur la conversation. \|
15		-\| `skills/compare-agents` \| Skill : poser la même question à Jan et à Lucy et comparer. \|
16	13	\| `skills/bg-jobs` \| Copie de la skill générale (le prompt de Bob y fait référence). \|
17	14
18	15	Dans `agent.llmman.yaml` :
19	16
20	17	```yaml
21	18	mmConfigs:
22		- jan: agent.jan-nano.yaml
23		- lucy: agent.lucy.yaml
24		- reviewer: agent.lucy-reviewer.yaml
	19	+ jan:
	20	+ path: agent.jan-nano.yaml
	21	+ description: Research and fact questions — looks things up and answers in a few lines.
	22	+ lucy:
	23	+ path: agent.lucy.yaml
	24	+ description: A coding agent — reads, writes and runs code in this project. …
	25	+ yolo: true
	26	+ reviewer:
	27	+ path: agent.lucy-reviewer.yaml
	28	+ description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
25	29	```
26	30
27	31	## Prérequis
@@ -86,58 +90,56 @@ printf 'User: My name is Philippe and I like Go.\nAssistant: Nice to meet you, P
86	90	- La question vient de `-p`, sinon de stdin. Pour `--ask-with-context`, stdin contient le contexte ; sans `-p`, le contexte, une ligne `---`, puis la question.
87	91	- stdout ne contient que la réponse (`answer=$(../mm agent.llmman.yaml --ask jan -p "…")` marche) ; l'en-tête, les appels d'outils et les erreurs vont sur stderr.
88	92	- Codes de sortie : `0` réponse obtenue, `1` échec (raison sur stderr, par exemple `[ask: unknown agent "spock" — agents in this config: jan, lucy, reviewer]`), `130` interrompu.
89		-- Les outils de l'agent appelé sont autorisés dans ce mode. Pour un agent qui doit seulement répondre, utilisez `reviewer`.
	93	+- Les appels d'outils de l'agent appelé suivent le `yolo` de son entrée dans `mmConfigs` (Lucy : `true`, ils s'exécutent), sinon celui de `agent.llmman.yaml` (`false` : refusés, personne ne peut répondre). Pour un agent qui doit seulement répondre, utilisez `reviewer`.
90	94
91		-## 3. Laisser Bob interroger les autres via ses skills
	95	+## 3. Laisser Bob décider : l'outil `ask_agent`
92	96
93		-Bob exporte `MM_BIN` (son propre binaire) et `MM_CONFIG` (sa configuration) vers les commandes de son outil bash. Les skills appellent donc simplement `"$MM_BIN" --ask …`, sans connaître aucun chemin. Demandez en langage courant :
	97	+Comme `mmConfigs` n'est pas vide, Bob dispose de l'outil intégré `ask_agent`. Sa description liste Jan, Lucy et le relecteur avec leur `description` : c'est Bob qui choisit, sans skill. Demandez en langage courant :
94	98
95		-\| Vous dites \| Skill \| Commande lancée par Bob \|
96		-\|---\|---\|---\|
97		-\| « Ask Jan what the capital of Peru is. » \| `delegate-to-jan` \| `"$MM_BIN" --ask jan -p "What is the capital of Peru?"` \|
98		-\| « I think Go's goroutines are OS threads. Get a second opinion from Lucy on that claim. » \| `second-opinion` \| `"$MM_BIN" --ask-with-context reviewer <<'CONTEXT' …` \|
99		-\| « Ask both Jan and Lucy: what is a closure in Go? » \| `compare-agents` \| les deux `--ask` dans une seule commande \|
	99	+\| Vous dites \| Bob appelle \|
	100	+\|---\|---\|
	101	+\| « Ask Jan what the capital of Peru is. » \| `ask_agent` → `jan` \|
	102	+\| « I think Go's goroutines are OS threads. Get a second opinion on that claim. » \| `ask_agent` → `reviewer`, avec `with_context` \|
	103	+\| « Ask Lucy to add a test for main.go and run it. » \| `ask_agent` → `lucy`, dont les écritures et commandes s'exécutent sans demander (`yolo: true` dans son entrée) \|
100	104
101		-Exemple réel (`second-opinion`, 97 s au total) :
	105	+Bob a `yolo: false` : vous approuvez d'abord chaque passage de main, avec le prompt qu'il a écrit. Dans la fenêtre (`../mm -tui agent.llmman.yaml`), l'agent appelé est nommé pendant qu'il travaille :
102	106
103	107	```text
104		-📖 read_skill: second-opinion
105		-🛠️ bash: "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
106		-User: I think Go's goroutines are OS threads.
107		-Assistant: Actually, Go goroutines are not OS threads. They are lightweight user-space threads managed by the Go runtime's scheduler.
108		----
109		-Is Go's goroutine implementation OS threads?
110		-CONTEXT
111		- │ 🗣 asking reviewer (llmman/hf.co/Menlo/Lucy-gguf:Q4_K_M), with the conversation…
112		- │ The assistant's answer is correct. Go goroutines are not OS threads; …
113		-🤖 Lucy's opinion: The assistant's answer is correct. … I agree with Lucy.
	108	+mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
	109	+…
	110	+‣ mm [Jan (coding agent)]
	111	+The capital of Peru is Lima.
114	112	```
115	113
116		-`compare-agents` n'a pas encore été testée en conditions réelles.
	114	+puis l'en-tête revient à Bob, qui conclut sous `‣ mm [Bob (coordinator)]`. Mesuré : 6 s pour Jan, 5,6 s pour le relecteur (`mm -p`, modèles déjà chargés).
	115	+
	116	+La réponse revient à Bob comme résultat de l'outil, dans le même tour ; elle n'est pas ajoutée à l'historique comme avec `/ask`.
117	117
118	118	## Réglages de temps
119	119
120	120	Un petit modèle local peut mettre une minute à répondre. `agent.llmman.yaml` relève donc deux délais :
121	121
122	122	```yaml
123		-watchdogTimeout: 3m # le watchdog continue de compter pendant qu'une commande tourne (ticket 57)
124		-bashTimeout: 3m # durée maximale d'une commande bash (30s par défaut)
	123	+watchdogTimeout: 3m # silence toléré ; pendant ask_agent, chaque événement de l'agent appelé compte comme signe de vie
	124	+bashTimeout: 3m # durée maximale d'une commande bash (30s par défaut), pour un script qui lance mm --ask
125	125	```
126	126
127		-Avec les valeurs par défaut, une skill qui interroge un agent finit en `[error: 30s timeout exceeded]` ou `connection hang detected after 30s`.
	127	+Avec `ask_agent`, seul un long silence de l'agent appelé (le chargement de son modèle, la lecture d'un long premier prompt) peut encore dépasser `watchdogTimeout`.
128	128
129	129	## Bon à savoir
130	130
131		-- Petits modèles, tous outils : Lucy (1,7B) avec ses outils, quand on lui demande seulement un avis, a tendance à s'égarer — lire des fichiers, charger des skills, en écrire. D'où le profil `reviewer` sans outils pour `second-opinion`.
132		-- Une seule fois : le modèle de Bob (4B) a parfois relancé la même question ; les skills lui disent explicitement de lancer la commande une seule fois.
133		-- Anglais : ces modèles répondent mieux aux questions en anglais ; les skills leur font écrire la question en anglais.
	131	+- Petits modèles, tous outils : Lucy (1,7B) avec ses outils, quand on lui demande seulement un avis, a tendance à s'égarer — lire des fichiers, charger des skills, en écrire. D'où le profil `reviewer` sans outils pour les deuxièmes avis.
	132	+- Une seule fois : le modèle de Bob (4B) a parfois relancé la même question ; son prompt lui dit d'appeler `ask_agent` une seule fois par tâche.
	133	+- Anglais : ces modèles répondent mieux aux questions en anglais.
134	134	- Pas de sessions chez les agents appelés : ils tournent avec `AGENT_SESSIONS=off`, donc vos `/sessions` ne listent que celles de Bob.
135	135	- Profondeur limitée : Bob peut interroger Jan, Jan peut interroger un autre agent, mais ce dernier ne peut plus interroger personne (`MM_ASK_DEPTH`).
136	136	- Noms : une skill ne doit pas porter le nom d'une commande générée (`ask-jan`…) ; mm le signale au démarrage.
	137	+- Les skills de délégation (`delegate-to-jan`, `second-opinion`, `compare-agents`) qui faisaient lancer `mm --ask` à Bob ont été retirées au profit d'`ask_agent` ; elles restent dans l'historique git (commit 8941766) et le guide sur les skills en montre une.
137	138
138	139	## Pour aller plus loin
139	140
140	141	- [Comment interroger un autre agent mm depuis votre session](../docs/fr/how-to/ask-another-agent.md)
	142	+- [Comment laisser votre agent appeler d'autres agents](../docs/fr/how-to/let-the-agent-call-other-agents.md)
141	143	- [Comment interroger un autre agent depuis une skill ou un script](../docs/fr/how-to/ask-another-agent-from-a-skill.md)
142	144	- [Référence des commandes slash](../docs/fr/reference/slash-commands.md#interroger-un-autre-agent) · [Référence de la ligne de commande](../docs/fr/reference/cli.md#spécificités-du-mode-ask)
143	145	- [Pourquoi c'est construit ainsi](../docs/fr/explanation/asking-another-agent.md)

  | Fichier | Rôle |
  |---|---|
--| `agent.llmman.yaml` | **Bob**, l'agent que vous lancez (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Déclare les autres agents sous `mmConfigs` et charge les skills de `skills/`. |
++| `agent.llmman.yaml` | **Bob**, l'agent que vous lancez (`hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M`). Déclare les autres agents sous `mmConfigs`, avec une description et, pour Lucy, son propre `yolo`. |
  | `agent.jan-nano.yaml` | **Jan** (`hf.co/Menlo/Jan-nano-gguf:Q4_K_M`), agent complet avec ses outils. |
  | `agent.lucy.yaml` | **Lucy** (`hf.co/Menlo/Lucy-gguf:Q4_K_M`), agent complet avec ses outils. |
  | `agent.lucy-reviewer.yaml` | **reviewer** : le modèle de Lucy **sans outils ni skills**, avec un prompt de relecteur. Il ne fait que répondre. |
--| `skills/delegate-to-jan` | Skill : déléguer une question à Jan. |
--| `skills/second-opinion` | Skill : demander au relecteur un deuxième avis sur la conversation. |
--| `skills/compare-agents` | Skill : poser la même question à Jan et à Lucy et comparer. |
  | `skills/bg-jobs` | Copie de la skill générale (le prompt de Bob y fait référence). |
  Dans `agent.llmman.yaml` :
  ```yaml
  mmConfigs:
--  jan: agent.jan-nano.yaml
++  jan:
--  lucy: agent.lucy.yaml
++    path: agent.jan-nano.yaml
--  reviewer: agent.lucy-reviewer.yaml
++    description: Research and fact questions — looks things up and answers in a few lines.
++  lucy:
++    path: agent.lucy.yaml
++    description: A coding agent — reads, writes and runs code in this project. …
++    yolo: true
++  reviewer:
++    path: agent.lucy-reviewer.yaml
++    description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
  ```
  ## Prérequis
  - La question vient de `-p`, sinon de stdin. Pour `--ask-with-context`, stdin contient le contexte ; sans `-p`, le contexte, une ligne `---`, puis la question.
  - **stdout ne contient que la réponse** (`answer=$(../mm agent.llmman.yaml --ask jan -p "…")` marche) ; l'en-tête, les appels d'outils et les erreurs vont sur stderr.
  - Codes de sortie : `0` réponse obtenue, `1` échec (raison sur stderr, par exemple `[ask: unknown agent "spock" — agents in this config: jan, lucy, reviewer]`), `130` interrompu.
--- Les outils de l'agent appelé sont **autorisés** dans ce mode. Pour un agent qui doit seulement répondre, utilisez `reviewer`.
++- Les appels d'outils de l'agent appelé suivent le `yolo` de son entrée dans `mmConfigs` (Lucy : `true`, ils s'exécutent), sinon celui de `agent.llmman.yaml` (`false` : refusés, personne ne peut répondre). Pour un agent qui doit seulement répondre, utilisez `reviewer`.
--## 3. Laisser Bob interroger les autres via ses skills
++## 3. Laisser Bob décider : l'outil `ask_agent`
--Bob exporte `MM_BIN` (son propre binaire) et `MM_CONFIG` (sa configuration) vers les commandes de son outil bash. Les skills appellent donc simplement `"$MM_BIN" --ask …`, sans connaître aucun chemin. Demandez en langage courant :
++Comme `mmConfigs` n'est pas vide, Bob dispose de l'outil intégré `ask_agent`. Sa description liste Jan, Lucy et le relecteur avec leur `description` : c'est Bob qui choisit, sans skill. Demandez en langage courant :
--| Vous dites | Skill | Commande lancée par Bob |
++| Vous dites | Bob appelle |
--|---|---|---|
++|---|---|
--| « Ask Jan what the capital of Peru is. » | `delegate-to-jan` | `"$MM_BIN" --ask jan -p "What is the capital of Peru?"` |
++| « Ask Jan what the capital of Peru is. » | `ask_agent` → `jan` |
--| « I think Go's goroutines are OS threads. Get a second opinion from Lucy on that claim. » | `second-opinion` | `"$MM_BIN" --ask-with-context reviewer <<'CONTEXT' …` |
++| « I think Go's goroutines are OS threads. Get a second opinion on that claim. » | `ask_agent` → `reviewer`, avec `with_context` |
--| « Ask both Jan and Lucy: what is a closure in Go? » | `compare-agents` | les deux `--ask` dans une seule commande |
++| « Ask Lucy to add a test for main.go and run it. » | `ask_agent` → `lucy`, dont les écritures et commandes s'exécutent sans demander (`yolo: true` dans son entrée) |
--Exemple réel (`second-opinion`, 97 s au total) :
++Bob a `yolo: false` : vous approuvez d'abord chaque passage de main, avec le prompt qu'il a écrit. Dans la fenêtre (`../mm -tui agent.llmman.yaml`), l'agent appelé est nommé pendant qu'il travaille :
  ```text
--📖 read_skill: second-opinion
++mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
--🛠️  bash: "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
++…
--User: I think Go's goroutines are OS threads.
++‣ mm [Jan (coding agent)]
--Assistant: Actually, Go goroutines are not OS threads. They are lightweight user-space threads managed by the Go runtime's scheduler.
++The capital of Peru is Lima.
-----
--Is Go's goroutine implementation OS threads?
--CONTEXT
--   │ 🗣 asking reviewer (llmman/hf.co/Menlo/Lucy-gguf:Q4_K_M), with the conversation…
--   │ The assistant's answer is correct. Go goroutines are not OS threads; …
--🤖 Lucy's opinion: The assistant's answer is correct. … I agree with Lucy.
  ```
--`compare-agents` n'a pas encore été testée en conditions réelles.
++puis l'en-tête revient à Bob, qui conclut sous `‣ mm [Bob (coordinator)]`. Mesuré : 6 s pour Jan, 5,6 s pour le relecteur (`mm -p`, modèles déjà chargés).
++
++La réponse revient à Bob comme résultat de l'outil, dans le même tour ; elle n'est pas ajoutée à l'historique comme avec `/ask`.
  ## Réglages de temps
  Un petit modèle local peut mettre une minute à répondre. `agent.llmman.yaml` relève donc deux délais :
  ```yaml
--watchdogTimeout: 3m   # le watchdog continue de compter pendant qu'une commande tourne (ticket 57)
++watchdogTimeout: 3m   # silence toléré ; pendant ask_agent, chaque événement de l'agent appelé compte comme signe de vie
--bashTimeout: 3m       # durée maximale d'une commande bash (30s par défaut)
++bashTimeout: 3m       # durée maximale d'une commande bash (30s par défaut), pour un script qui lance mm --ask
  ```
--Avec les valeurs par défaut, une skill qui interroge un agent finit en `[error: 30s timeout exceeded]` ou `connection hang detected after 30s`.
++Avec `ask_agent`, seul un long silence de l'agent appelé (le chargement de son modèle, la lecture d'un long premier prompt) peut encore dépasser `watchdogTimeout`.
  ## Bon à savoir
--- **Petits modèles, tous outils** : Lucy (1,7B) avec ses outils, quand on lui demande seulement un avis, a tendance à s'égarer — lire des fichiers, charger des skills, en écrire. D'où le profil `reviewer` sans outils pour `second-opinion`.
++- **Petits modèles, tous outils** : Lucy (1,7B) avec ses outils, quand on lui demande seulement un avis, a tendance à s'égarer — lire des fichiers, charger des skills, en écrire. D'où le profil `reviewer` sans outils pour les deuxièmes avis.
--- **Une seule fois** : le modèle de Bob (4B) a parfois relancé la même question ; les skills lui disent explicitement de lancer la commande une seule fois.
++- **Une seule fois** : le modèle de Bob (4B) a parfois relancé la même question ; son prompt lui dit d'appeler `ask_agent` une seule fois par tâche.
--- **Anglais** : ces modèles répondent mieux aux questions en anglais ; les skills leur font écrire la question en anglais.
++- **Anglais** : ces modèles répondent mieux aux questions en anglais.
  - **Pas de sessions chez les agents appelés** : ils tournent avec `AGENT_SESSIONS=off`, donc vos `/sessions` ne listent que celles de Bob.
  - **Profondeur limitée** : Bob peut interroger Jan, Jan peut interroger un autre agent, mais ce dernier ne peut plus interroger personne (`MM_ASK_DEPTH`).
  - **Noms** : une skill ne doit pas porter le nom d'une commande générée (`ask-jan`…) ; mm le signale au démarrage.
++- **Les skills de délégation** (`delegate-to-jan`, `second-opinion`, `compare-agents`) qui faisaient lancer `mm --ask` à Bob ont été retirées au profit d'`ask_agent` ; elles restent dans l'historique git (commit 8941766) et le guide sur les skills en montre une.
  ## Pour aller plus loin
  - [Comment interroger un autre agent mm depuis votre session](../docs/fr/how-to/ask-another-agent.md)
++- [Comment laisser votre agent appeler d'autres agents](../docs/fr/how-to/let-the-agent-call-other-agents.md)
  - [Comment interroger un autre agent depuis une skill ou un script](../docs/fr/how-to/ask-another-agent-from-a-skill.md)
  - [Référence des commandes slash](../docs/fr/reference/slash-commands.md#interroger-un-autre-agent) · [Référence de la ligne de commande](../docs/fr/reference/cli.md#spécificités-du-mode-ask)
  - [Pourquoi c'est construit ainsi](../docs/fr/explanation/asking-another-agent.md)

modified demo-llmman/agent.llmman.yaml +41 -14 Viewed

@@ -17,18 +17,37 @@ baseUrl: http://127.0.0.1:17434/v1
17	17	# From a Docker sandbox, the daemon runs on the host.
18	18	fallback: http://host.docker.internal:17434/v1
19	19
20		-# Other mm agents this one can ask. Each name becomes /ask-<name> and
21		-# /ask-with-context-<name> (also `/ask <name> <prompt>` in the terminal and the
22		-# window); the answer is shown and kept in the history for the next question.
23		-# Each agent runs as a child `mm -acp` started on its first /ask. Paths are
	20	+# Other mm agents this one can ask. Two ways:
	21	+# - YOU type /ask-<name> or /ask-with-context-<name> (also `/ask <name> …`);
	22	+# the answer is shown and kept in the history for the next question;
	23	+# - BOB decides, with the `ask_agent` tool (declared because this list is
	24	+# not empty): he picks an agent from its `description`, the agent works
	25	+# in front of you (the window names it in its header and above its
	26	+# answer), and its answer comes back to Bob as the tool's result.
	27	+# Each agent runs as a child `mm -acp` started on its first ask. Paths are
24	28	# relative to THIS file's directory. Names: lowercase letters, digits and '-'.
	29	+#
	30	+# An entry is a path, or {path, description, yolo}:
	31	+# description when to call this agent — what ask_agent shows Bob.
	32	+# yolo decides THIS agent's tool calls instead of Bob's yolo:
	33	+# true = they run, false = each one is asked. Absent = Bob's
	34	+# yolo decides (false here: you approve each call).
25	35	mmConfigs:
26		- jan: agent.jan-nano.yaml
27		- lucy: agent.lucy.yaml
28		- # Lucy's model with no tools and a reviewer prompt: what the second-opinion
29		- # skill asks. A small model with every tool wanders (reads files, loads
30		- # skills) when it is only asked for an opinion.
31		- reviewer: agent.lucy-reviewer.yaml
	36	+ jan:
	37	+ path: agent.jan-nano.yaml
	38	+ description: Research and fact questions — looks things up and answers in a few lines.
	39	+ lucy:
	40	+ path: agent.lucy.yaml
	41	+ description: A coding agent — reads, writes and runs code in this project. Give it the files to change and the check to run.
	42	+ # Lucy's writes and commands run without asking once you approved the
	43	+ # hand-off: coding is her job.
	44	+ yolo: true
	45	+ # Lucy's model with no tools and a reviewer prompt. A small model with
	46	+ # every tool wanders (reads files, loads skills) when it is only asked for
	47	+ # an opinion.
	48	+ reviewer:
	49	+ path: agent.lucy-reviewer.yaml
	50	+ description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
32	51
33	52	acp:
34	53	name: bob
@@ -143,6 +162,14 @@ system: \|
143	162	you invent. Match the request against that list, call `read_skill` FIRST,
144	163	before any bash command, and then follow what it says step by step.
145	164
	165	+ OTHER AGENTS
	166	+ `ask_agent` hands a task to another agent; its description says which agent
	167	+ does what. Use it when the user names an agent, asks for a second opinion,
	168	+ or asks for something an agent there is for. Give it a complete prompt —
	169	+ it does not see this conversation unless with_context is true. Call it ONCE
	170	+ per task: its result is that agent's answer. Then answer the user, saying
	171	+ which agent answered and what it said; never answer in its place.
	172	+
146	173	FILE EDITING
147	174	You have three tools for files: `read_file`, `edit_file` and `write_file`.
148	175	They are how a file gets read and changed here: each change is exact,
@@ -201,10 +228,10 @@ sampling:
201	228	# Silence allowed between two tokens once the answer has started.
202	229	watchdogTimeout: 3m
203	230
204		-# How long one bash command may run (default 30s). The demo skills call jan and
205		-# lucy with "$MM_BIN" --ask, which can take a minute or two with small local
206		-# models. The watchdog above keeps counting while a command runs (ticket 57),
207		-# so it is raised to the same value.
	231	+# How long one bash command may run (default 30s). The watchdog above keeps
	232	+# counting while a command runs (ticket 57), so the two move together.
	233	+# (ask_agent is not bash: the asked agent's activity keeps Bob's watchdog
	234	+# alive, and its own watchdog stops it if it hangs.)
208	235	bashTimeout: 3m
209	236
210	237	# Silence allowed while the model reads the prompt, before the first token:

  # From a Docker sandbox, the daemon runs on the host.
  fallback: http://host.docker.internal:17434/v1
--# Other mm agents this one can ask. Each name becomes /ask-<name> and
++# Other mm agents this one can ask. Two ways:
--# /ask-with-context-<name> (also `/ask <name> <prompt>` in the terminal and the
++#   - YOU type /ask-<name> or /ask-with-context-<name> (also `/ask <name> …`);
--# window); the answer is shown and kept in the history for the next question.
++#     the answer is shown and kept in the history for the next question;
--# Each agent runs as a child `mm -acp` started on its first /ask. Paths are
++#   - BOB decides, with the `ask_agent` tool (declared because this list is
++#     not empty): he picks an agent from its `description`, the agent works
++#     in front of you (the window names it in its header and above its
++#     answer), and its answer comes back to Bob as the tool's result.
++# Each agent runs as a child `mm -acp` started on its first ask. Paths are
  # relative to THIS file's directory. Names: lowercase letters, digits and '-'.
++#
++# An entry is a path, or {path, description, yolo}:
++#   description  when to call this agent — what ask_agent shows Bob.
++#   yolo         decides THIS agent's tool calls instead of Bob's yolo:
++#                true = they run, false = each one is asked. Absent = Bob's
++#                yolo decides (false here: you approve each call).
  mmConfigs:
--  jan: agent.jan-nano.yaml
++  jan:
--  lucy: agent.lucy.yaml
++    path: agent.jan-nano.yaml
--  # Lucy's model with no tools and a reviewer prompt: what the second-opinion
++    description: Research and fact questions — looks things up and answers in a few lines.
--  # skill asks. A small model with every tool wanders (reads files, loads
++  lucy:
--  # skills) when it is only asked for an opinion.
++    path: agent.lucy.yaml
--  reviewer: agent.lucy-reviewer.yaml
++    description: A coding agent — reads, writes and runs code in this project. Give it the files to change and the check to run.
++    # Lucy's writes and commands run without asking once you approved the
++    # hand-off: coding is her job.
++    yolo: true
++  # Lucy's model with no tools and a reviewer prompt. A small model with
++  # every tool wanders (reads files, loads skills) when it is only asked for
++  # an opinion.
++  reviewer:
++    path: agent.lucy-reviewer.yaml
++    description: A second opinion on an answer or a claim from this conversation — call it with with_context true. No tools.
  acp:
    name: bob
    you invent. Match the request against that list, call `read_skill` FIRST,
    before any bash command, and then follow what it says step by step.
++  OTHER AGENTS
++  `ask_agent` hands a task to another agent; its description says which agent
++  does what. Use it when the user names an agent, asks for a second opinion,
++  or asks for something an agent there is for. Give it a complete prompt —
++  it does not see this conversation unless with_context is true. Call it ONCE
++  per task: its result is that agent's answer. Then answer the user, saying
++  which agent answered and what it said; never answer in its place.
++
    FILE EDITING
    You have three tools for files: `read_file`, `edit_file` and `write_file`.
    They are how a file gets read and changed here: each change is exact,
  # Silence allowed between two tokens once the answer has started.
  watchdogTimeout: 3m
--# How long one bash command may run (default 30s). The demo skills call jan and
++# How long one bash command may run (default 30s). The watchdog above keeps
--# lucy with "$MM_BIN" --ask, which can take a minute or two with small local
++# counting while a command runs (ticket 57), so the two move together.
--# models. The watchdog above keeps counting while a command runs (ticket 57),
++# (ask_agent is not bash: the asked agent's activity keeps Bob's watchdog
--# so it is raised to the same value.
++# alive, and its own watchdog stops it if it hangs.)
  bashTimeout: 3m
  # Silence allowed while the model reads the prompt, before the first token:

deleted demo-llmman/skills/compare-agents/SKILL.md +0 -23 Viewed

deleted file mode 100644
@@ -1,23 +0,0 @@
1		----
2		-name: compare-agents
3		-description: Ask the same question to Jan and to Lucy, two other agents, and compare their answers.
4		-keywords: compare, both agents, jan and lucy, ask both, compare les, les deux, comparer
5		----
6		-
7		-# Compare Jan and Lucy
8		-
9		-## When to use it
10		-
11		-The user wants to compare agents, or asks you to ask both Jan and Lucy.
12		-
13		-## What to do
14		-
15		-Write the question in English, as one self-contained sentence (neither agent sees this conversation). Then call your `bash` tool ONCE with both commands, so the two answers come back together:
16		-
17		- echo "## Jan"; "$MM_BIN" --ask jan -p "<question>"; echo; echo "## Lucy"; "$MM_BIN" --ask lucy -p "<question>"
18		-
19		-- Each command prints the agent's answer, and only that. The pair can take a few minutes.
20		-- Run it ONCE. Whatever it prints are the answers: do not run it again.
21		-- A line starting with `[ask:` means that agent could not answer: say so for that agent.
22		-
23		-Then answer the user with a short comparison: what Jan said, what Lucy said, where they agree, where they differ. Do not add an answer of your own unless the user asks for it.

-----
--name: compare-agents
--description: Ask the same question to Jan and to Lucy, two other agents, and compare their answers.
--keywords: compare, both agents, jan and lucy, ask both, compare les, les deux, comparer
-----
--
--# Compare Jan and Lucy
--
--## When to use it
--
--The user wants to compare agents, or asks you to ask both Jan and Lucy.
--
--## What to do
--
--Write the question in English, as one self-contained sentence (neither agent sees this conversation). Then call your `bash` tool ONCE with both commands, so the two answers come back together:
--
--    echo "## Jan"; "$MM_BIN" --ask jan -p "<question>"; echo; echo "## Lucy"; "$MM_BIN" --ask lucy -p "<question>"
--
--- Each command prints the agent's answer, and only that. The pair can take a few minutes.
--- Run it ONCE. Whatever it prints are the answers: do not run it again.
--- A line starting with `[ask:` means that agent could not answer: say so for that agent.
--
--Then answer the user with a short comparison: what Jan said, what Lucy said, where they agree, where they differ. Do not add an answer of your own unless the user asks for it.

deleted demo-llmman/skills/delegate-to-jan/SKILL.md +0 -23 Viewed

deleted file mode 100644
@@ -1,23 +0,0 @@
1		----
2		-name: delegate-to-jan
3		-description: Delegate a research or fact question to Jan, another agent (Jan-nano 4B), and report Jan's answer.
4		-keywords: jan, delegate, research, look up, other agent, demande à jan, cherche, recherche
5		----
6		-
7		-# Delegate to Jan
8		-
9		-## When to use it
10		-
11		-The user asks you to ask Jan, or to delegate a question to another agent, or wants a fact you cannot check with a command.
12		-
13		-## What to do
14		-
15		-Call your `bash` tool with this command, replacing `<question>` with the user's question, in English, as one self-contained sentence (Jan does not see this conversation):
16		-
17		- "$MM_BIN" --ask jan -p "<question>"
18		-
19		-- The command prints Jan's answer, and only that. It can take a minute.
20		-- Run it ONCE. Whatever it prints is the answer: do not run it again, do not rephrase and ask again.
21		-- If it prints `[ask: …]` instead, Jan could not answer: tell the user that line, do not answer in Jan's place.
22		-
23		-Then answer the user in a few lines, starting with "Jan says:" — Jan's answer, not yours.

-----
--name: delegate-to-jan
--description: Delegate a research or fact question to Jan, another agent (Jan-nano 4B), and report Jan's answer.
--keywords: jan, delegate, research, look up, other agent, demande à jan, cherche, recherche
-----
--
--# Delegate to Jan
--
--## When to use it
--
--The user asks you to ask Jan, or to delegate a question to another agent, or wants a fact you cannot check with a command.
--
--## What to do
--
--Call your `bash` tool with this command, replacing `<question>` with the user's question, in English, as one self-contained sentence (Jan does not see this conversation):
--
--    "$MM_BIN" --ask jan -p "<question>"
--
--- The command prints Jan's answer, and only that. It can take a minute.
--- Run it ONCE. Whatever it prints is the answer: do not run it again, do not rephrase and ask again.
--- If it prints `[ask: …]` instead, Jan could not answer: tell the user that line, do not answer in Jan's place.
--
--Then answer the user in a few lines, starting with "Jan says:" — Jan's answer, not yours.

deleted demo-llmman/skills/second-opinion/SKILL.md +0 -28 Viewed

deleted file mode 100644
@@ -1,28 +0,0 @@
1		----
2		-name: second-opinion
3		-description: Get a second opinion from Lucy, a reviewer agent (Lucy 1.7B, no tools), on the conversation so far.
4		-keywords: second opinion, lucy, review, double-check, avis, deuxième avis, vérifie, relis
5		----
6		-
7		-# Second opinion from Lucy
8		-
9		-## When to use it
10		-
11		-The user wants a second opinion, a review of your last answer, or asks what Lucy thinks.
12		-
13		-## What to do
14		-
15		-Lucy does not see this conversation: you send it to her. Call your `bash` tool with this command, replacing the lines between `CONTEXT` and `---` with a short summary of the conversation — one `User:` or `Assistant:` line per message, the last answer included — and `<question>` with what to check, in English:
16		-
17		- "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
18		- User: <first question>
19		- Assistant: <your answer>
20		- ---
21		- <question>
22		- CONTEXT
23		-
24		-- The command prints Lucy's answer, and only that. It can take a minute.
25		-- Run it ONCE. Whatever it prints is Lucy's opinion: do not run it again, do not rephrase the question and ask again, even if you disagree with her.
26		-- If it prints `[ask: …]` instead, tell the user that Lucy could not answer, with that line.
27		-
28		-Then answer the user: "Lucy's opinion:" followed by her answer, then one sentence saying whether you agree and why.

-----
--name: second-opinion
--description: Get a second opinion from Lucy, a reviewer agent (Lucy 1.7B, no tools), on the conversation so far.
--keywords: second opinion, lucy, review, double-check, avis, deuxième avis, vérifie, relis
-----
--
--# Second opinion from Lucy
--
--## When to use it
--
--The user wants a second opinion, a review of your last answer, or asks what Lucy thinks.
--
--## What to do
--
--Lucy does not see this conversation: you send it to her. Call your `bash` tool with this command, replacing the lines between `CONTEXT` and `---` with a short summary of the conversation — one `User:` or `Assistant:` line per message, the last answer included — and `<question>` with what to check, in English:
--
--    "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
--    User: <first question>
--    Assistant: <your answer>
--    ---
--    <question>
--    CONTEXT
--
--- The command prints Lucy's answer, and only that. It can take a minute.
--- Run it ONCE. Whatever it prints is Lucy's opinion: do not run it again, do not rephrase the question and ask again, even if you disagree with her.
--- If it prints `[ask: …]` instead, tell the user that Lucy could not answer, with that line.
--
--Then answer the user: "Lucy's opinion:" followed by her answer, then one sentence saying whether you agree and why.

modified docs/en/README.md +3 -2 Viewed

@@ -14,7 +14,8 @@ This documentation is organised along the four [Diátaxis](https://diataxis.fr)
14	14	- [Run mini-me on llmman](how-to/run-with-llmman.md) — `provider: llmman`, the demo config in `demo-llmman/`
15	15	- [Run mini-me on Ollama](how-to/run-with-ollama.md) — `provider: ollama`, the demo config in `demo-ollama/`
16	16	- [Ask another mm agent from your session](how-to/ask-another-agent.md) — `mmConfigs`, `/ask-<name>`, `/ask-with-context-<name>`
17		-- [Ask another agent from a skill or a script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`, the demo skills
	17	+- [Let your agent call other agents](how-to/let-the-agent-call-other-agents.md) — `ask_agent`, `mmConfigs` descriptions, per-agent `yolo`
	18	+- [Ask another agent from a skill or a script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`
18	19	- [Use mini-me from an editor (ACP)](how-to/use-from-an-editor.md)
19	20	- [Turn a model's reasoning off](how-to/turn-reasoning-off.md) — `chat_template_kwargs` or `reasoning_effort` in `sampling`, per server
20	21	- [Confirm tool calls before they run](how-to/confirm-tool-calls.md) — `yolo: false`, the four answers, `AGENT_YOLO`, who decides with `mmConfigs`
@@ -61,7 +62,7 @@ This documentation is organised along the four [Diátaxis](https://diataxis.fr)
61	62	- [The `fetch_content` tool](explanation/fetch-content-tool.md) — why a built-in tool beside MCP `fetch`, a home-made converter, robots.txt, errors as numbered text, known limits
62	63	- [Thinking models](explanation/thinking-models.md) — where a model's reasoning comes from, why `mm` reads it below Genkit, and why reading it keeps the watchdog alive
63	64	- [Yolo mode and permissions](explanation/yolo-and-permissions.md) — why tools run unasked by default, existing versus asking, four answers in one package, why the asking agent decides
64		-- [Asking another agent](explanation/asking-another-agent.md) — why another mm agent is a child process spoken to over ACP, the history pair, fresh sessions, the depth limit
	65	+- [Asking another agent](explanation/asking-another-agent.md) — why another mm agent is a child process spoken to over ACP, the history pair, fresh sessions, `ask_agent` and per-agent `yolo`, the depth limit
65	66	- Package diagram (draw.io source): [`docs/diagrams/packages.drawio`](../diagrams/packages.drawio)
66	67
67	68	### MCP (Model Context Protocol) Explanation

  - [Run mini-me on llmman](how-to/run-with-llmman.md) — `provider: llmman`, the demo config in `demo-llmman/`
  - [Run mini-me on Ollama](how-to/run-with-ollama.md) — `provider: ollama`, the demo config in `demo-ollama/`
  - [Ask another mm agent from your session](how-to/ask-another-agent.md) — `mmConfigs`, `/ask-<name>`, `/ask-with-context-<name>`
--- [Ask another agent from a skill or a script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`, the demo skills
++- [Let your agent call other agents](how-to/let-the-agent-call-other-agents.md) — `ask_agent`, `mmConfigs` descriptions, per-agent `yolo`
++- [Ask another agent from a skill or a script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`
  - [Use mini-me from an editor (ACP)](how-to/use-from-an-editor.md)
  - [Turn a model's reasoning off](how-to/turn-reasoning-off.md) — `chat_template_kwargs` or `reasoning_effort` in `sampling`, per server
  - [Confirm tool calls before they run](how-to/confirm-tool-calls.md) — `yolo: false`, the four answers, `AGENT_YOLO`, who decides with `mmConfigs`
  - [The `fetch_content` tool](explanation/fetch-content-tool.md) — why a built-in tool beside MCP `fetch`, a home-made converter, robots.txt, errors as numbered text, known limits
  - [Thinking models](explanation/thinking-models.md) — where a model's reasoning comes from, why `mm` reads it below Genkit, and why reading it keeps the watchdog alive
  - [Yolo mode and permissions](explanation/yolo-and-permissions.md) — why tools run unasked by default, existing versus asking, four answers in one package, why the asking agent decides
--- [Asking another agent](explanation/asking-another-agent.md) — why another mm agent is a child process spoken to over ACP, the history pair, fresh sessions, the depth limit
++- [Asking another agent](explanation/asking-another-agent.md) — why another mm agent is a child process spoken to over ACP, the history pair, fresh sessions, `ask_agent` and per-agent `yolo`, the depth limit
  - Package diagram (draw.io source): [`docs/diagrams/packages.drawio`](../diagrams/packages.drawio)
  ### MCP (Model Context Protocol) Explanation

modified docs/en/explanation/asking-another-agent.md +7 -4 Viewed

@@ -2,7 +2,7 @@
2	2
3	3	## What is this about?
4	4
5		-`/ask-bob <prompt>` lets the agent you are talking to consult another mm agent: another model, another system prompt, other tools and skills. Bob's answer is shown, then kept in your conversation so your own model can use it on your next question. This page explains how that is built and why.
	5	+`/ask-bob <prompt>` lets the agent you are talking to consult another mm agent: another model, another system prompt, other tools and skills. Bob's answer is shown, then kept in your conversation so your own model can use it on your next question. The `ask_agent` tool lets your model do the same by itself, when a request matches what an agent is for. This page explains how that is built and why.
6	6
7	7	## Why it is designed this way
8	8
@@ -10,7 +10,7 @@
10	10
11	11	The two talk ACP. mm already speaks the Agent Client Protocol as a server, for editors. Asking bob makes the asking agent an ACP client of its child. The protocol gives, for free, what scraping a terminal never would: bob's answer as text, his tool calls as structured events, his permission requests as requests that can be answered, and a standard way to cancel. mm's ACP server only ever calls two client methods — session updates and permission requests — so the client side is small; file and terminal requests are refused as absent.
12	12
13		-Bob's permissions are yours to give. Bob is started with `AGENT_YOLO=false`, so every call he would gate becomes a permission request to your agent, and YOUR `yolo` decides: on, it runs; off, the question goes to the front end you are using — the editor's dialog, the window's box, the line mode's `🔐` prompt — exactly as for your own agent's tools there. The `yolo` in bob's own file does not count while he answers you. Bob's tools are named `bob/<tool>`, so allowing your agent's `bash` "for this session" does not allow bob's. See [Yolo mode and permissions](yolo-and-permissions.md).
	13	+Bob's permissions are yours to give. Bob is started with `AGENT_YOLO=false`, so every call he would gate becomes a permission request to your agent, and YOUR `yolo` decides: on, it runs; off, the question goes to the front end you are using — the editor's dialog, the window's box, the line mode's `🔐` prompt — exactly as for your own agent's tools there. The `yolo` in bob's own file does not count while he answers you — the one in YOUR file's entry for him does: `mmConfigs: {bob: {path: …, yolo: true}}` lets bob's calls run while yours still ask (a coder you trust with edits once you approved the hand-off), `yolo: false` asks for each of his calls even when yours run freely. Bob's tools are named `bob/<tool>`, so allowing your agent's `bash` "for this session" does not allow bob's. See [Yolo mode and permissions](yolo-and-permissions.md).
14	14
15	15	The answer is a pair of messages. It enters your history as a user message (`[asked bob (provider/model): …]`) followed by an assistant message (`[bob's answer]` and the text). One message would have been simpler, but your next question is a user message too, and several chat templates (Gemma's, Mistral's) refuse two user messages in a row. The marks say who said what, so your model does not mistake bob's answer for its own. The answer is capped like a tool's output, at `maxOutput` characters: it lands in your model's window.
16	16
@@ -20,11 +20,13 @@
20	20
21	21	The child is fenced off from what is meant for its parent. Variables like `AGENT_MODEL`, `AGENT_PROVIDER` or `AGENT_BASE_URL` override a configuration; inherited by bob, they would silently turn him into a copy of you. They are removed from his environment. Bob also runs with `AGENT_SESSIONS=off`: he works in your project, and his session files would otherwise appear in your `/sessions` and `/resume`.
22	22
23		-Chains stop. `/ask` is a command a person types; no model can call it, so no agent loops on its own. A person could still type `/ask` into an agent that was itself asked, so each child is told its depth (`MM_ASK_DEPTH`): your agent may ask bob, bob may ask riker, riker may not ask anyone.
	23	+Your model can decide too: `ask_agent`. With `mmConfigs` set, your agent gets a built-in tool that asks one of the agents and returns its answer as the tool's result. Its description lists the agents with what each is for — the entry's `description`, else the agent's `acp.title` — and that is all the model has to choose from, so a description says when to call the agent, not who it is. The tool runs on the same pool and protocol as `/ask`, inside the turn: the agent's text, thoughts and tool calls stream through your front end as they happen, and the window names it while it works — its title and model in the header, `asked by` your agent, its answer labelled with its name. The call itself is gated like `bash`: with `yolo: false` you see the prompt your model wrote before it goes. The answer is a tool result, not a `/ask` pair in the history: your model reads it and carries on in the same turn — report it, check it, hand the next step to another agent.
	24	+
	25	+Chains stop. A model calling `ask_agent` from an agent that was itself asked could go on asking; each child is told its depth (`MM_ASK_DEPTH`): your agent may ask bob, bob may ask riker, riker may not ask anyone — whether by a typed `/ask` or by `ask_agent`.
24	26
25	27	The same machinery answers scripts. `mm --ask <agent>` and `mm --ask-with-context <agent>` are the slash commands for whatever can only run a command — a skill, a script. They start the same child over ACP, with the same environment fence and depth limit, but the answer goes to stdout and everything else to stderr, so a caller captures the answer alone. mm exports `MM_BIN` and `MM_CONFIG` to the commands its `bash` tool runs, so a skill calls "this mm, with this configuration" without knowing either path. Two things differ from the slash commands, both because the caller is a command and not a person. The agent's tool calls follow the calling configuration's `yolo`: allowed when it is on — the person already approved the `mm --ask` command itself —, rejected when it is off, since stdin carried the question and nobody is there to answer. And `mm --ask` watches its parent process: the `bash` tool kills `bash` when its budget runs out, not bash's children, and an orphaned ask kept its agent running — and writing files — after nobody waited for it any more.
26	28
27		-Time is the weak point. A local model can take a minute to answer, and one `bash` command had 30 seconds; `bashTimeout` now sets that budget. The watchdog of the asking agent also keeps counting while a command runs (ticket 57), so it has to be raised too until that ticket is fixed.
	29	+Time is the weak point. A local model can take a minute to answer, and one `bash` command had 30 seconds; `bashTimeout` now sets that budget. The watchdog of the asking agent also keeps counting while a command runs (ticket 57), so it has to be raised too until that ticket is fixed. `ask_agent` does better because it sees the agent work: every event the agent streams — text, a thought, a tool call — counts as a sign of life for your agent's watchdog. Only a long silence still ends the turn: an agent loading a large model, or reading a long first prompt, so `watchdogTimeout` must cover that much.
28	30
29	31	## Rejected alternatives
30	32
@@ -32,6 +34,7 @@
32	34	- A second engine in the same process. Fast, no process — at the price of turning the global configuration into a per-agent one throughout the code base.
33	35	- Letting the current model answer at once with bob's input. The user chose otherwise: bob's answer is shown and kept, and you decide what to ask next.
34	36	- Keeping bob's own conversation across asks. Two conversations evolving in parallel, one of them invisible, are harder to reason about than an explicit transcript sent when asked.
	37	+- Skills that run `mm --ask` for the model. It works — a skill per hand-off, the command in its text — and `mm --ask` stays for scripts. But the agent's work reaches you as the output of one `bash` command: no name in the header, no label on its answer, its tool calls as text lines. And a small coordinator must copy a long command exactly: measured with Gemma 4 E4B, it dropped the quotes and an `AGENT_YOLO=true` prefix, so the coder it called could not write. A tool call with an `agent` and a `prompt` has nothing to copy.
35	38	- A generic `/ask <name>` only, in editors too. An editor's `/` menu completes a command name, never its argument; one command per agent is the only way for the menu to list the agents.
36	39
37	40	## How it relates to the rest

  ## What is this about?
--`/ask-bob <prompt>` lets the agent you are talking to consult another mm agent: another model, another system prompt, other tools and skills. Bob's answer is shown, then kept in your conversation so your own model can use it on your next question. This page explains how that is built and why.
++`/ask-bob <prompt>` lets the agent you are talking to consult another mm agent: another model, another system prompt, other tools and skills. Bob's answer is shown, then kept in your conversation so your own model can use it on your next question. The `ask_agent` tool lets your model do the same by itself, when a request matches what an agent is for. This page explains how that is built and why.
  ## Why it is designed this way
  **The two talk ACP.** mm already speaks the Agent Client Protocol as a server, for editors. Asking bob makes the asking agent an ACP *client* of its child. The protocol gives, for free, what scraping a terminal never would: bob's answer as text, his tool calls as structured events, his permission requests as requests that can be answered, and a standard way to cancel. mm's ACP server only ever calls two client methods — session updates and permission requests — so the client side is small; file and terminal requests are refused as absent.
--**Bob's permissions are yours to give.** Bob is started with `AGENT_YOLO=false`, so every call he would gate becomes a permission request to your agent, and YOUR `yolo` decides: on, it runs; off, the question goes to the front end you are using — the editor's dialog, the window's box, the line mode's `🔐` prompt — exactly as for your own agent's tools there. The `yolo` in bob's own file does not count while he answers you. Bob's tools are named `bob/<tool>`, so allowing your agent's `bash` "for this session" does not allow bob's. See [Yolo mode and permissions](yolo-and-permissions.md).
++**Bob's permissions are yours to give.** Bob is started with `AGENT_YOLO=false`, so every call he would gate becomes a permission request to your agent, and YOUR `yolo` decides: on, it runs; off, the question goes to the front end you are using — the editor's dialog, the window's box, the line mode's `🔐` prompt — exactly as for your own agent's tools there. The `yolo` in bob's own file does not count while he answers you — the one in YOUR file's entry for him does: `mmConfigs: {bob: {path: …, yolo: true}}` lets bob's calls run while yours still ask (a coder you trust with edits once you approved the hand-off), `yolo: false` asks for each of his calls even when yours run freely. Bob's tools are named `bob/<tool>`, so allowing your agent's `bash` "for this session" does not allow bob's. See [Yolo mode and permissions](yolo-and-permissions.md).
  **The answer is a pair of messages.** It enters your history as a user message (`[asked bob (provider/model): …]`) followed by an assistant message (`[bob's answer]` and the text). One message would have been simpler, but your next question is a user message too, and several chat templates (Gemma's, Mistral's) refuse two user messages in a row. The marks say who said what, so your model does not mistake bob's answer for its own. The answer is capped like a tool's output, at `maxOutput` characters: it lands in your model's window.
  **The child is fenced off from what is meant for its parent.** Variables like `AGENT_MODEL`, `AGENT_PROVIDER` or `AGENT_BASE_URL` override a configuration; inherited by bob, they would silently turn him into a copy of you. They are removed from his environment. Bob also runs with `AGENT_SESSIONS=off`: he works in your project, and his session files would otherwise appear in your `/sessions` and `/resume`.
--**Chains stop.** `/ask` is a command a person types; no model can call it, so no agent loops on its own. A person could still type `/ask` into an agent that was itself asked, so each child is told its depth (`MM_ASK_DEPTH`): your agent may ask bob, bob may ask riker, riker may not ask anyone.
++**Your model can decide too: `ask_agent`.** With `mmConfigs` set, your agent gets a built-in tool that asks one of the agents and returns its answer as the tool's result. Its description lists the agents with what each is for — the entry's `description`, else the agent's `acp.title` — and that is all the model has to choose from, so a description says when to call the agent, not who it is. The tool runs on the same pool and protocol as `/ask`, inside the turn: the agent's text, thoughts and tool calls stream through your front end as they happen, and the window names it while it works — its title and model in the header, `asked by` your agent, its answer labelled with its name. The call itself is gated like `bash`: with `yolo: false` you see the prompt your model wrote before it goes. The answer is a tool result, not a `/ask` pair in the history: your model reads it and carries on in the same turn — report it, check it, hand the next step to another agent.
++
++**Chains stop.** A model calling `ask_agent` from an agent that was itself asked could go on asking; each child is told its depth (`MM_ASK_DEPTH`): your agent may ask bob, bob may ask riker, riker may not ask anyone — whether by a typed `/ask` or by `ask_agent`.
  **The same machinery answers scripts.** `mm --ask <agent>` and `mm --ask-with-context <agent>` are the slash commands for whatever can only run a command — a skill, a script. They start the same child over ACP, with the same environment fence and depth limit, but the answer goes to stdout and everything else to stderr, so a caller captures the answer alone. mm exports `MM_BIN` and `MM_CONFIG` to the commands its `bash` tool runs, so a skill calls "this mm, with this configuration" without knowing either path. Two things differ from the slash commands, both because the caller is a command and not a person. The agent's tool calls follow the calling configuration's `yolo`: allowed when it is on — the person already approved the `mm --ask` command itself —, rejected when it is off, since stdin carried the question and nobody is there to answer. And `mm --ask` watches its parent process: the `bash` tool kills `bash` when its budget runs out, not bash's children, and an orphaned ask kept its agent running — and writing files — after nobody waited for it any more.
--**Time is the weak point.** A local model can take a minute to answer, and one `bash` command had 30 seconds; `bashTimeout` now sets that budget. The watchdog of the asking agent also keeps counting while a command runs (ticket 57), so it has to be raised too until that ticket is fixed.
++**Time is the weak point.** A local model can take a minute to answer, and one `bash` command had 30 seconds; `bashTimeout` now sets that budget. The watchdog of the asking agent also keeps counting while a command runs (ticket 57), so it has to be raised too until that ticket is fixed. `ask_agent` does better because it sees the agent work: every event the agent streams — text, a thought, a tool call — counts as a sign of life for your agent's watchdog. Only a long silence still ends the turn: an agent loading a large model, or reading a long first prompt, so `watchdogTimeout` must cover that much.
  ## Rejected alternatives
  - **A second engine in the same process.** Fast, no process — at the price of turning the global configuration into a per-agent one throughout the code base.
  - **Letting the current model answer at once with bob's input.** The user chose otherwise: bob's answer is shown and kept, and you decide what to ask next.
  - **Keeping bob's own conversation across asks.** Two conversations evolving in parallel, one of them invisible, are harder to reason about than an explicit transcript sent when asked.
++- **Skills that run `mm --ask` for the model.** It works — a skill per hand-off, the command in its text — and `mm --ask` stays for scripts. But the agent's work reaches you as the output of one `bash` command: no name in the header, no label on its answer, its tool calls as text lines. And a small coordinator must copy a long command exactly: measured with Gemma 4 E4B, it dropped the quotes and an `AGENT_YOLO=true` prefix, so the coder it called could not write. A tool call with an `agent` and a `prompt` has nothing to copy.
  - **A generic `/ask <name>` only, in editors too.** An editor's `/` menu completes a command name, never its argument; one command per agent is the only way for the menu to list the agents.
  ## How it relates to the rest

modified docs/en/how-to/ask-another-agent-from-a-skill.md +24 -5 Viewed

@@ -1,6 +1,6 @@
1	1	# How to ask another agent from a skill or a script
2	2
3		-This guide shows how to make a skill — or any shell script — put a question to another mm agent and use its answer. It assumes the agents are already declared under `mmConfigs` (see [how to ask another agent](ask-another-agent.md)).
	3	+This guide shows how to make a skill — or any shell script — put a question to another mm agent and use its answer. It assumes the agents are already declared under `mmConfigs` (see [how to ask another agent](ask-another-agent.md)). For your model to hand work to another agent on its own, the [`ask_agent` tool](let-the-agent-call-other-agents.md) is the simpler way: no command to copy, and the window shows which agent is working. A skill is for a fixed procedure, a script, or several agents in one command.
4	4
5	5	## Steps
6	6
@@ -25,11 +25,30 @@ This guide shows how to make a skill — or any shell script — put a question
25	25
26	26	The model writes this summary itself: a command cannot read the conversation.
27	27
28		-3. Tell the model, in the skill, to run the command once and to report the answer as the other agent's. `demo-llmman/skills/` has three complete examples:
	28	+3. Tell the model, in the skill, to run the command once and to report the answer as the other agent's. A complete skill (`skills/second-opinion/SKILL.md`):
29	29
30		- - `delegate-to-jan` — a question delegated to Jan;
31		- - `second-opinion` — the conversation sent to a reviewer;
32		- - `compare-agents` — the same question to Jan and Lucy, in one command.
	30	+ ```markdown
	31	+ ---
	32	+ name: second-opinion
	33	+ description: Get a second opinion from the reviewer agent on a claim or an answer from this conversation.
	34	+ keywords: second opinion, review, check, deuxième avis, vérifie, relis
	35	+ ---
	36	+
	37	+ # Second opinion
	38	+
	39	+ Call your `bash` tool ONCE with this command, the conversation summarised in English above the `---` line, the question below it:
	40	+
	41	+ "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
	42	+ User: <the claim>
	43	+ Assistant: <your answer, if any>
	44	+ ---
	45	+ Is this right? Correct it if not.
	46	+ CONTEXT
	47	+
	48	+ What it prints is the reviewer's answer. Report it, starting with "The reviewer says:"; never answer in its place. If it prints `[ask: …]`, tell the user that line.
	49	+ ```
	50	+
	51	+ Keep such a command short: a small model copies a long one inexactly (quotes, prefixes).
33	52
34	53	4. Raise the time limits in the asking agent's configuration. A local model can take a minute to answer, and both limits default to well under that:
35	54

  # How to ask another agent from a skill or a script
--This guide shows how to make a skill — or any shell script — put a question to another mm agent and use its answer. It assumes the agents are already declared under `mmConfigs` (see [how to ask another agent](ask-another-agent.md)).
++This guide shows how to make a skill — or any shell script — put a question to another mm agent and use its answer. It assumes the agents are already declared under `mmConfigs` (see [how to ask another agent](ask-another-agent.md)). For your model to hand work to another agent on its own, the [`ask_agent` tool](let-the-agent-call-other-agents.md) is the simpler way: no command to copy, and the window shows which agent is working. A skill is for a fixed procedure, a script, or several agents in one command.
  ## Steps
     The model writes this summary itself: a command cannot read the conversation.
--3. Tell the model, in the skill, to run the command once and to report the answer as the other agent's. `demo-llmman/skills/` has three complete examples:
++3. Tell the model, in the skill, to run the command once and to report the answer as the other agent's. A complete skill (`skills/second-opinion/SKILL.md`):
--   - `delegate-to-jan` — a question delegated to Jan;
++   ```markdown
--   - `second-opinion` — the conversation sent to a reviewer;
++   ---
--   - `compare-agents` — the same question to Jan and Lucy, in one command.
++   name: second-opinion
++   description: Get a second opinion from the reviewer agent on a claim or an answer from this conversation.
++   keywords: second opinion, review, check, deuxième avis, vérifie, relis
++   ---
++
++   # Second opinion
++
++   Call your `bash` tool ONCE with this command, the conversation summarised in English above the `---` line, the question below it:
++
++       "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
++       User: <the claim>
++       Assistant: <your answer, if any>
++       ---
++       Is this right? Correct it if not.
++       CONTEXT
++
++   What it prints is the reviewer's answer. Report it, starting with "The reviewer says:"; never answer in its place. If it prints `[ask: …]`, tell the user that line.
++   ```
++
++   Keep such a command short: a small model copies a long one inexactly (quotes, prefixes).
 . Raise the time limits in the asking agent's configuration. A local model can take a minute to answer, and both limits default to well under that:

added docs/en/how-to/let-the-agent-call-other-agents.md +73 -0 Viewed

new file mode 100644
@@ -0,0 +1,73 @@
	1	+# How to let your agent call other agents
	2	+
	3	+This guide shows how to give your agent a team: other mm agents it hands work to by itself, with the built-in `ask_agent` tool, while you watch which one is working. It assumes you already run `mm` with a configuration file, and have one configuration file per agent you want it to call.
	4	+
	5	+## Steps
	6	+
	7	+1. List the agents under `mmConfigs`, each with a `description` that says when to call it — the description is all your model has to choose from:
	8	+
	9	+ ```yaml
	10	+ mmConfigs:
	11	+ milo:
	12	+ path: agent.milo.yaml
	13	+ description: Specifier. Turns a request into a specification saved in specs/<slug>.spec.md, and checks code against a specification.
	14	+ homer:
	15	+ path: agent.homer.yaml
	16	+ description: Coder. Implements a specification file from specs/, with tests. Call him only once a specification exists.
	17	+ ```
	18	+
	19	+ Paths are relative to the file you write them in. A plain `name: path` entry still works; it is described by the agent's `acp.title`.
	20	+
	21	+2. Decide who approves the agents' own tool calls. By default your agent's `yolo` decides for them too. Give an agent its own `yolo` to change that:
	22	+
	23	+ ```yaml
	24	+ homer:
	25	+ path: agent.homer.yaml
	26	+ description: …
	27	+ yolo: true # his edits and commands run without asking
	28	+ ```
	29	+
	30	+ With your own `yolo: false`, you still approve each hand-off — the `ask_agent` call, with the prompt your model wrote — and then homer works on his own.
	31	+
	32	+3. Tell your model, in its `system` prompt, when to hand work over and what to do with the answer. For instance:
	33	+
	34	+ ```yaml
	35	+ system: \|
	36	+ …
	37	+ OTHER AGENTS
	38	+ `ask_agent` hands a task to another agent; its description says which
	39	+ agent does what. Give it a complete prompt. Call it ONCE per task: its
	40	+ result is that agent's answer. Then answer the user, saying which agent
	41	+ answered; never answer in its place.
	42	+ ```
	43	+
	44	+4. Start `mm` and check that the banner lists `ask_agent` among the tools:
	45	+
	46	+ ```text
	47	+ mm … \| tools: bash, read_skill, read_file, write_file, edit_file, plan, ask_agent \| …
	48	+ ```
	49	+
	50	+5. Ask something an agent is for, in plain language. In the window (`mm -tui`), the header switches to the agent while it works, and its answer carries its name:
	51	+
	52	+ ```text
	53	+ mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
	54	+ …
	55	+ ‣ mm [Jan (coding agent)]
	56	+ The capital of Peru is Lima.
	57	+ ```
	58	+
	59	+ Then the header comes back to your agent, which carries on from the answer.
	60	+
	61	+## Variants
	62	+
	63	+- Send the conversation along. The model sets `with_context: true` when the agent needs what was said — a reviewer giving a second opinion. Say so in the agent's description ("call it with with_context true").
	64	+- Ask an agent yourself. `/ask-<name>` and `/ask-with-context-<name>` still work, and keep the exchange in the history. See [How to ask another mm agent](ask-another-agent.md).
	65	+- Long work. Each event the agent streams keeps your agent's watchdog alive, but a long silence — a large model loading, a long first prompt — does not: raise your `watchdogTimeout` to cover it (10m for a 48 GB model on a laptop).
	66	+- From a script. `mm --ask <name>` remains the way for a shell command. See [How to ask another agent from a skill or a script](ask-another-agent-from-a-skill.md).
	67	+- Working examples. `demo-llmman/agent.llmman.yaml` (Bob with Jan, Lucy and a reviewer) and `mini-mes/riker/agent.riker.yaml` (a coordinator, a specifier and a coder).
	68	+
	69	+## See also
	70	+
	71	+- The tool's fields, display and errors: [tools reference](../reference/tools.md#ask_agent)
	72	+- The two forms of `mmConfigs`: [configuration reference](../reference/configuration.md)
	73	+- Why it runs inside the turn rather than through a skill: [asking another agent — explanation](../explanation/asking-another-agent.md)

++# How to let your agent call other agents
++
++This guide shows how to give your agent a team: other mm agents it hands work to by itself, with the built-in `ask_agent` tool, while you watch which one is working. It assumes you already run `mm` with a configuration file, and have one configuration file per agent you want it to call.
++
++## Steps
++
++1. List the agents under `mmConfigs`, each with a `description` that says **when** to call it — the description is all your model has to choose from:
++
++   ```yaml
++   mmConfigs:
++     milo:
++       path: agent.milo.yaml
++       description: Specifier. Turns a request into a specification saved in specs/<slug>.spec.md, and checks code against a specification.
++     homer:
++       path: agent.homer.yaml
++       description: Coder. Implements a specification file from specs/, with tests. Call him only once a specification exists.
++   ```
++
++   Paths are relative to the file you write them in. A plain `name: path` entry still works; it is described by the agent's `acp.title`.
++
++2. Decide who approves the agents' own tool calls. By default your agent's `yolo` decides for them too. Give an agent its own `yolo` to change that:
++
++   ```yaml
++     homer:
++       path: agent.homer.yaml
++       description: …
++       yolo: true    # his edits and commands run without asking
++   ```
++
++   With your own `yolo: false`, you still approve each hand-off — the `ask_agent` call, with the prompt your model wrote — and then homer works on his own.
++
++3. Tell your model, in its `system` prompt, when to hand work over and what to do with the answer. For instance:
++
++   ```yaml
++   system: |
++     …
++     OTHER AGENTS
++     `ask_agent` hands a task to another agent; its description says which
++     agent does what. Give it a complete prompt. Call it ONCE per task: its
++     result is that agent's answer. Then answer the user, saying which agent
++     answered; never answer in its place.
++   ```
++
++4. Start `mm` and check that the banner lists `ask_agent` among the tools:
++
++   ```text
++   mm … | tools: bash, read_skill, read_file, write_file, edit_file, plan, ask_agent | …
++   ```
++
++5. Ask something an agent is for, in plain language. In the window (`mm -tui`), the header switches to the agent while it works, and its answer carries its name:
++
++   ```text
++   mm [Jan (coding agent)] · Jan-nano:Q4_K_M @ llmman · asked by mm [Bob (coordinator)]
++   …
++   ‣ mm [Jan (coding agent)]
++   The capital of Peru is Lima.
++   ```
++
++   Then the header comes back to your agent, which carries on from the answer.
++
++## Variants
++
++- **Send the conversation along.** The model sets `with_context: true` when the agent needs what was said — a reviewer giving a second opinion. Say so in the agent's description ("call it with with_context true").
++- **Ask an agent yourself.** `/ask-<name>` and `/ask-with-context-<name>` still work, and keep the exchange in the history. See [How to ask another mm agent](ask-another-agent.md).
++- **Long work.** Each event the agent streams keeps your agent's watchdog alive, but a long silence — a large model loading, a long first prompt — does not: raise your `watchdogTimeout` to cover it (10m for a 48 GB model on a laptop).
++- **From a script.** `mm --ask <name>` remains the way for a shell command. See [How to ask another agent from a skill or a script](ask-another-agent-from-a-skill.md).
++- **Working examples.** `demo-llmman/agent.llmman.yaml` (Bob with Jan, Lucy and a reviewer) and `mini-mes/riker/agent.riker.yaml` (a coordinator, a specifier and a coder).
++
++## See also
++
++- The tool's fields, display and errors: [tools reference](../reference/tools.md#ask_agent)
++- The two forms of `mmConfigs`: [configuration reference](../reference/configuration.md)
++- Why it runs inside the turn rather than through a skill: [asking another agent — explanation](../explanation/asking-another-agent.md)

modified docs/en/reference/configuration.md +2 -2 Viewed

@@ -33,7 +33,7 @@
33	33	\| `tui` \| bool \| `false` \| Start in the single-window mode without the `-tui` flag. Falls back to the line mode when stdin or stdout is not a terminal; ignored with `-acp`. \|
34	34	\| `yolo` \| bool \| `true` \| `true`: the tools run without asking. `false`: every call that changes something — `bash`, `write_file`, `edit_file`, `fetch_content` with `output`, `lsp` `rename`, `plan` `create`/`update`/`next`/`delete` — waits for the user's answer in every front end (line mode, window, editor), and so does every MCP tool, whatever `mcp.permissions` says. Answers: allow once, allow this tool for the session, reject this call, never (this tool, for the session). `read_file`, `read_skill`, `fetch_content` without `output` and the `lsp` navigation actions never ask. In `-p` and `mm --ask`, nobody can answer: those calls are rejected. An agent started by `/ask` runs with `AGENT_YOLO=false` and submits its calls to the asking agent, whose `yolo` decides. Overridden by `AGENT_YOLO`. `bashTool`, `editTools`, `fetchContentTool` still decide which tools exist. See [How to confirm tool calls](../how-to/confirm-tool-calls.md). \|
35	35	\| `permissions` \| string \| absent \| Deprecated, replaced by `yolo`. `ask` = `yolo: false` (and wins over `yolo: true`); `auto` changes nothing. Either value adds a start-up warning. Must be `auto` or `ask`. \|
36		-\| `mmConfigs` \| map name → path \| none \| Other mm agents this one can ask. Each name generates `/ask-<name>` and `/ask-with-context-<name>` (see [slash commands](slash-commands.md#asking-another-agent)). A relative path is relative to the directory of the file that declares it. Names: lowercase letters, digits and `-`, starting with a letter or a digit, not starting with `with-context`. A path whose file does not exist is a start-up warning, not an error. \|
	36	+\| `mmConfigs` \| map name → path, or name → `{path, description, yolo}` \| none \| Other mm agents this one can ask. Each name generates `/ask-<name>` and `/ask-with-context-<name>` (see [slash commands](slash-commands.md#asking-another-agent)), and the list declares the [`ask_agent`](tools.md#ask_agent) tool, through which the model calls them itself. The long form adds `description` (when to call that agent; shown in `ask_agent`'s description, falling back to the agent file's `acp.title`) and `yolo` (decides that agent's tool calls when it is asked, by `/ask`, `ask_agent` or `mm --ask`, instead of this agent's `yolo`: `true` they run, `false` each one is asked; absent, this agent's `yolo` decides). `path` must not be empty. A relative path is relative to the directory of the file that declares it. Names: lowercase letters, digits and `-`, starting with a letter or a digit, not starting with `with-context`. A path whose file does not exist is a start-up warning, not an error. \|
37	37
38	38	## `context` keys
39	39
@@ -124,7 +124,7 @@ Reported as `[config error: <path>: <message>]`, exit code 1.
124	124	\| `bashTimeout must be > 0` \| zero or negative \|
125	125	\| `mmConfigs: "Bob" is not a valid name (…)` \| a name with uppercase letters, spaces or other characters, or starting with `-` \|
126	126	\| `mmConfigs: "with-context-x" is not a valid name (it would read as /ask-with-context-…)` \| a name starting with `with-context` \|
127		-\| `mmConfigs.<name>: the path must not be empty` \| `<name>: ""` \|
	127	+\| `mmConfigs.<name>: the path must not be empty` \| `<name>: ""`, or a long form without `path` \|
128	128	\| `unknown provider "x" (known: dmr, llamacpp, llmman, ollama)` \| Reported by the engine, as `[engine error: …]`. \|
129	129
130	130	A start-up warning, not an error, is printed when `context.enabled` is `true`, the window is unknown and `context.maxMessages` is `0`, and when the file sets the deprecated `permissions` key (`permissions: ask is deprecated — use yolo: false instead …`).

  | `tui` | bool | `false` | Start in the single-window mode without the `-tui` flag. Falls back to the line mode when stdin or stdout is not a terminal; ignored with `-acp`. |
  | `yolo` | bool | `true` | `true`: the tools run without asking. `false`: every call that changes something — `bash`, `write_file`, `edit_file`, `fetch_content` with `output`, `lsp` `rename`, `plan` `create`/`update`/`next`/`delete` — waits for the user's answer in every front end (line mode, window, editor), and so does every MCP tool, whatever `mcp.permissions` says. Answers: allow once, allow this tool for the session, reject this call, never (this tool, for the session). `read_file`, `read_skill`, `fetch_content` without `output` and the `lsp` navigation actions never ask. In `-p` and `mm --ask`, nobody can answer: those calls are rejected. An agent started by `/ask` runs with `AGENT_YOLO=false` and submits its calls to the asking agent, whose `yolo` decides. Overridden by `AGENT_YOLO`. `bashTool`, `editTools`, `fetchContentTool` still decide which tools exist. See [How to confirm tool calls](../how-to/confirm-tool-calls.md). |
  | `permissions` | string | absent | Deprecated, replaced by `yolo`. `ask` = `yolo: false` (and wins over `yolo: true`); `auto` changes nothing. Either value adds a start-up warning. Must be `auto` or `ask`. |
--| `mmConfigs` | map name → path | none | Other mm agents this one can ask. Each name generates `/ask-<name>` and `/ask-with-context-<name>` (see [slash commands](slash-commands.md#asking-another-agent)). A relative path is relative to the directory of the file that declares it. Names: lowercase letters, digits and `-`, starting with a letter or a digit, not starting with `with-context`. A path whose file does not exist is a start-up warning, not an error. |
++| `mmConfigs` | map name → path, or name → `{path, description, yolo}` | none | Other mm agents this one can ask. Each name generates `/ask-<name>` and `/ask-with-context-<name>` (see [slash commands](slash-commands.md#asking-another-agent)), and the list declares the [`ask_agent`](tools.md#ask_agent) tool, through which the model calls them itself. The long form adds `description` (when to call that agent; shown in `ask_agent`'s description, falling back to the agent file's `acp.title`) and `yolo` (decides that agent's tool calls when it is asked, by `/ask`, `ask_agent` or `mm --ask`, instead of this agent's `yolo`: `true` they run, `false` each one is asked; absent, this agent's `yolo` decides). `path` must not be empty. A relative path is relative to the directory of the file that declares it. Names: lowercase letters, digits and `-`, starting with a letter or a digit, not starting with `with-context`. A path whose file does not exist is a start-up warning, not an error. |
  ## `context` keys
  | `bashTimeout must be > 0` | zero or negative |
  | `mmConfigs: "Bob" is not a valid name (…)` | a name with uppercase letters, spaces or other characters, or starting with `-` |
  | `mmConfigs: "with-context-x" is not a valid name (it would read as /ask-with-context-…)` | a name starting with `with-context` |
--| `mmConfigs.<name>: the path must not be empty` | `<name>: ""` |
++| `mmConfigs.<name>: the path must not be empty` | `<name>: ""`, or a long form without `path` |
  | `unknown provider "x" (known: dmr, llamacpp, llmman, ollama)` | Reported by the engine, as `[engine error: …]`. |
  A start-up warning, not an error, is printed when `context.enabled` is `true`, the window is unknown and `context.maxMessages` is `0`, and when the file sets the deprecated `permissions` key (`permissions: ask is deprecated — use yolo: false instead …`).

modified docs/en/reference/tools.md +22 -0 Viewed

@@ -200,6 +200,28 @@ Declared only with `fetchContentTool: true`. Downloads a web page and returns it
200	200	\| `2` \| `input` \| Host unreachable, timeout, HTTP status ≥ 300 after redirections, more than 10 redirections, robots.txt forbids the page or cannot be read. \|
201	201	\| `3` \| `usage` \| Empty or unparsable `url`, a scheme other than `http`/`https`, unknown `tables` value, `baseUrl` not absolute. \|
202	202
	203	+## `ask_agent`
	204	+
	205	+Declared when `mmConfigs` names at least one agent. Hands a task to one of them and returns its answer as the tool's result: the model decides when, from the agents' descriptions. Same machinery as `/ask` (package `internal/ask`): the agent runs as a child `mm -acp`, started on its first call and reused, with a fresh session per call.
	206	+
	207	+\| Field \| Type \| Default \| Description \|
	208	+\|-------\|------\|---------\|-------------\|
	209	+\| `agent` \| string \| — \| A name of `mmConfigs`. \|
	210	+\| `prompt` \| string \| — \| The task, complete and self-contained. \|
	211	+\| `with_context` \| bool \| `false` \| Send this conversation before the prompt: the history the turn started from (questions, answers, one line per tool call, never tool outputs), capped at `maxOutput` characters, newest kept. \|
	212	+
	213	+\| Aspect \| Behaviour \|
	214	+\|--------\|-----------\|
	215	+\| Description \| A fixed paragraph, then `Agents:` and one ` <name> — <purpose>` line per agent, sorted by name. `<purpose>` is the entry's `description`, else the agent file's `acp.title` (unless it is the built-in one), else `(no description)`. \|
	216	+\| Permission \| The call itself is gated like `bash`: requested when `yolo: false`. \|
	217	+\| The asked agent's calls \| Decided by its entry's `yolo` in `mmConfigs` when set (`true` run, `false` asked), else by this agent's `yolo`. \|
	218	+\| Working directory \| The process directory in the terminal and the window; the session `cwd` in ACP. \|
	219	+\| Display \| The asked agent's text, thoughts and tool calls stream through the turn, its tool calls titled `<agent> · <title>`. The window names it while it works: header `mm [<acp.title>] · <model> @ <provider> · asked by <this agent>`, its answer under `‣ mm [<acp.title>]` (its `mmConfigs` name when it has no title). Line mode: `🗣 ask_agent: <agent> (<provider>/<model>) — <first line of the prompt>`, then the agent's output. \|
	220	+\| Watchdog \| Each event of the asked agent (text, thought, tool call, answered permission) counts as a sign of life for this agent's watchdog. Silence longer than `watchdogTimeout` — a model loading, a long prompt being read — still ends the turn. \|
	221	+\| Result \| The answer, truncated to `maxOutput`. The tool call's own output in the window and the editor is `<agent> answered (N characters)`: the answer has already streamed. Not added to the history as a `/ask` exchange: it is a tool result. \|
	222	+\| Errors \| `[ask_agent: unknown agent "x" — agents: a, b]`; `[ask_agent: the prompt is empty — say what <agent> must do]`; `[ask_agent: <agent> failed: <reason>]`; `[ask_agent: <agent> gave no answer]`; a cancelled or broken run returns what was answered, then `[ask_agent: <agent> stopped before finishing: <reason>]`. \|
	223	+\| Depth \| An asked agent may itself have `mmConfigs` and call `ask_agent`, up to two levels (`MM_ASK_DEPTH`); beyond, the call fails with the depth message. \|
	224	+
203	225	## Loop detection
204	226
205	227	Every tool records `(tool, input, output)` in the loop detector after each call.

  | `2` | `input` | Host unreachable, timeout, HTTP status ≥ 300 after redirections, more than 10 redirections, robots.txt forbids the page or cannot be read. |
  | `3` | `usage` | Empty or unparsable `url`, a scheme other than `http`/`https`, unknown `tables` value, `baseUrl` not absolute. |
++## `ask_agent`
++
++Declared when `mmConfigs` names at least one agent. Hands a task to one of them and returns its answer as the tool's result: the model decides when, from the agents' descriptions. Same machinery as `/ask` (package `internal/ask`): the agent runs as a child `mm -acp`, started on its first call and reused, with a fresh session per call.
++
++| Field | Type | Default | Description |
++|-------|------|---------|-------------|
++| `agent` | string | — | A name of `mmConfigs`. |
++| `prompt` | string | — | The task, complete and self-contained. |
++| `with_context` | bool | `false` | Send this conversation before the prompt: the history the turn started from (questions, answers, one line per tool call, never tool outputs), capped at `maxOutput` characters, newest kept. |
++
++| Aspect | Behaviour |
++|--------|-----------|
++| Description | A fixed paragraph, then `Agents:` and one `  <name> — <purpose>` line per agent, sorted by name. `<purpose>` is the entry's `description`, else the agent file's `acp.title` (unless it is the built-in one), else `(no description)`. |
++| Permission | The call itself is gated like `bash`: requested when `yolo: false`. |
++| The asked agent's calls | Decided by its entry's `yolo` in `mmConfigs` when set (`true` run, `false` asked), else by this agent's `yolo`. |
++| Working directory | The process directory in the terminal and the window; the session `cwd` in ACP. |
++| Display | The asked agent's text, thoughts and tool calls stream through the turn, its tool calls titled `<agent> · <title>`. The window names it while it works: header `mm [<acp.title>] · <model> @ <provider> · asked by <this agent>`, its answer under `‣ mm [<acp.title>]` (its `mmConfigs` name when it has no title). Line mode: `🗣 ask_agent: <agent> (<provider>/<model>) — <first line of the prompt>`, then the agent's output. |
++| Watchdog | Each event of the asked agent (text, thought, tool call, answered permission) counts as a sign of life for this agent's watchdog. Silence longer than `watchdogTimeout` — a model loading, a long prompt being read — still ends the turn. |
++| Result | The answer, truncated to `maxOutput`. The tool call's own output in the window and the editor is `<agent> answered (N characters)`: the answer has already streamed. Not added to the history as a `/ask` exchange: it is a tool result. |
++| Errors | `[ask_agent: unknown agent "x" — agents: a, b]`; `[ask_agent: the prompt is empty — say what <agent> must do]`; `[ask_agent: <agent> failed: <reason>]`; `[ask_agent: <agent> gave no answer]`; a cancelled or broken run returns what was answered, then `[ask_agent: <agent> stopped before finishing: <reason>]`. |
++| Depth | An asked agent may itself have `mmConfigs` and call `ask_agent`, up to two levels (`MM_ASK_DEPTH`); beyond, the call fails with the depth message. |
++
  ## Loop detection
  Every tool records `(tool, input, output)` in the loop detector after each call.

modified docs/fr/README.md +3 -2 Viewed

@@ -14,7 +14,8 @@ Cette documentation est organisée selon les quatre quadrants [Diátaxis](https:
14	14	- [Faire tourner mini-me sur llmman](how-to/run-with-llmman.md) — `provider: llmman`, la config de démo dans `demo-llmman/`
15	15	- [Faire tourner mini-me sur Ollama](how-to/run-with-ollama.md) — `provider: ollama`, la config de démo dans `demo-ollama/`
16	16	- [Interroger un autre agent mm depuis votre session](how-to/ask-another-agent.md) — `mmConfigs`, `/ask-<nom>`, `/ask-with-context-<nom>`
17		-- [Interroger un autre agent depuis une skill ou un script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`, les skills de démo
	17	+- [Laisser votre agent appeler d'autres agents](how-to/let-the-agent-call-other-agents.md) — `ask_agent`, descriptions dans `mmConfigs`, `yolo` par agent
	18	+- [Interroger un autre agent depuis une skill ou un script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`
18	19	- [Utiliser mini-me depuis un éditeur (ACP)](how-to/use-from-an-editor.md)
19	20	- [Couper le raisonnement d'un modèle](how-to/turn-reasoning-off.md) — `chat_template_kwargs` ou `reasoning_effort` dans `sampling`, selon le serveur
20	21	- [Confirmer les appels d'outils avant leur exécution](how-to/confirm-tool-calls.md) — `yolo: false`, les quatre réponses, `AGENT_YOLO`, qui décide avec `mmConfigs`
@@ -61,7 +62,7 @@ Cette documentation est organisée selon les quatre quadrants [Diátaxis](https:
61	62	- [L'outil `fetch_content`](explanation/fetch-content-tool.md) — pourquoi un outil intégré à côté du `fetch` MCP, un convertisseur maison, le robots.txt, des erreurs numérotées en texte, les limites connues
62	63	- [Modèles à raisonnement](explanation/thinking-models.md) — d'où vient le raisonnement d'un modèle, pourquoi `mm` le lit sous Genkit, et pourquoi le lire garde le chien de garde en vie
63	64	- [Le mode yolo et les permissions](explanation/yolo-and-permissions.md) — pourquoi les outils s'exécutent sans demander par défaut, exister ou demander, quatre réponses dans un seul paquet, pourquoi l'agent qui interroge décide
64		-- [Interroger un autre agent](explanation/asking-another-agent.md) — pourquoi un autre agent mm est un processus enfant interrogé en ACP, la paire de messages, les sessions neuves, la limite de profondeur
	65	+- [Interroger un autre agent](explanation/asking-another-agent.md) — pourquoi un autre agent mm est un processus enfant interrogé en ACP, la paire de messages, les sessions neuves, `ask_agent` et le `yolo` par agent, la limite de profondeur
65	66	- Diagramme des paquets (source draw.io) : [`docs/diagrams/packages.drawio`](../diagrams/packages.drawio)
66	67
67	68	### Explication MCP (Model Context Protocol)

  - [Faire tourner mini-me sur llmman](how-to/run-with-llmman.md) — `provider: llmman`, la config de démo dans `demo-llmman/`
  - [Faire tourner mini-me sur Ollama](how-to/run-with-ollama.md) — `provider: ollama`, la config de démo dans `demo-ollama/`
  - [Interroger un autre agent mm depuis votre session](how-to/ask-another-agent.md) — `mmConfigs`, `/ask-<nom>`, `/ask-with-context-<nom>`
--- [Interroger un autre agent depuis une skill ou un script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`, les skills de démo
++- [Laisser votre agent appeler d'autres agents](how-to/let-the-agent-call-other-agents.md) — `ask_agent`, descriptions dans `mmConfigs`, `yolo` par agent
++- [Interroger un autre agent depuis une skill ou un script](how-to/ask-another-agent-from-a-skill.md) — `"$MM_BIN" --ask <agent>`, `--ask-with-context`
  - [Utiliser mini-me depuis un éditeur (ACP)](how-to/use-from-an-editor.md)
  - [Couper le raisonnement d'un modèle](how-to/turn-reasoning-off.md) — `chat_template_kwargs` ou `reasoning_effort` dans `sampling`, selon le serveur
  - [Confirmer les appels d'outils avant leur exécution](how-to/confirm-tool-calls.md) — `yolo: false`, les quatre réponses, `AGENT_YOLO`, qui décide avec `mmConfigs`
  - [L'outil `fetch_content`](explanation/fetch-content-tool.md) — pourquoi un outil intégré à côté du `fetch` MCP, un convertisseur maison, le robots.txt, des erreurs numérotées en texte, les limites connues
  - [Modèles à raisonnement](explanation/thinking-models.md) — d'où vient le raisonnement d'un modèle, pourquoi `mm` le lit sous Genkit, et pourquoi le lire garde le chien de garde en vie
  - [Le mode yolo et les permissions](explanation/yolo-and-permissions.md) — pourquoi les outils s'exécutent sans demander par défaut, exister ou demander, quatre réponses dans un seul paquet, pourquoi l'agent qui interroge décide
--- [Interroger un autre agent](explanation/asking-another-agent.md) — pourquoi un autre agent mm est un processus enfant interrogé en ACP, la paire de messages, les sessions neuves, la limite de profondeur
++- [Interroger un autre agent](explanation/asking-another-agent.md) — pourquoi un autre agent mm est un processus enfant interrogé en ACP, la paire de messages, les sessions neuves, `ask_agent` et le `yolo` par agent, la limite de profondeur
  - Diagramme des paquets (source draw.io) : [`docs/diagrams/packages.drawio`](../diagrams/packages.drawio)
  ### Explication MCP (Model Context Protocol)

modified docs/fr/explanation/asking-another-agent.md +7 -4 Viewed

@@ -2,7 +2,7 @@
2	2
3	3	## De quoi s'agit-il ?
4	4
5		-`/ask-bob <prompt>` permet à l'agent avec qui vous parlez de consulter un autre agent mm : un autre modèle, un autre prompt système, d'autres outils et skills. La réponse de bob est affichée, puis gardée dans votre conversation pour que votre propre modèle s'en serve à votre question suivante. Cette page explique comment c'est construit et pourquoi.
	5	+`/ask-bob <prompt>` permet à l'agent avec qui vous parlez de consulter un autre agent mm : un autre modèle, un autre prompt système, d'autres outils et skills. La réponse de bob est affichée, puis gardée dans votre conversation pour que votre propre modèle s'en serve à votre question suivante. L'outil `ask_agent` permet à votre modèle de faire de même de lui-même, quand une demande correspond au rôle d'un agent. Cette page explique comment c'est construit et pourquoi.
6	6
7	7	## Pourquoi c'est conçu ainsi
8	8
@@ -10,7 +10,7 @@
10	10
11	11	Les deux parlent ACP. mm parle déjà l'Agent Client Protocol comme serveur, pour les éditeurs. Interroger bob fait de l'agent qui pose la question un client ACP de son enfant. Le protocole apporte gratuitement ce que lire un terminal n'aurait jamais donné : la réponse de bob sous forme de texte, ses appels d'outils comme des événements structurés, ses demandes de permission comme des requêtes auxquelles on peut répondre, et une façon standard d'annuler. Le serveur ACP de mm n'appelle que deux méthodes du client — les mises à jour de session et les demandes de permission — donc le côté client est petit ; les requêtes de fichiers et de terminal sont refusées comme absentes.
12	12
13		-Les permissions de bob, c'est vous qui les donnez. Bob est lancé avec `AGENT_YOLO=false` : chaque appel qu'il filtrerait devient une demande de permission adressée à votre agent, et c'est VOTRE `yolo` qui décide : activé, l'appel s'exécute ; désactivé, la question va à la façade que vous utilisez — le dialogue de l'éditeur, la zone de la fenêtre, l'invite `🔐` du mode ligne — exactement comme pour les outils de votre propre agent à cet endroit. Le `yolo` du fichier de bob ne compte pas tant qu'il vous répond. Les outils de bob s'appellent `bob/<outil>`, donc autoriser le `bash` de votre agent « pour cette session » n'autorise pas celui de bob. Voir [Le mode yolo et les permissions](yolo-and-permissions.md).
	13	+Les permissions de bob, c'est vous qui les donnez. Bob est lancé avec `AGENT_YOLO=false` : chaque appel qu'il filtrerait devient une demande de permission adressée à votre agent, et c'est VOTRE `yolo` qui décide : activé, l'appel s'exécute ; désactivé, la question va à la façade que vous utilisez — le dialogue de l'éditeur, la zone de la fenêtre, l'invite `🔐` du mode ligne — exactement comme pour les outils de votre propre agent à cet endroit. Le `yolo` du fichier de bob ne compte pas tant qu'il vous répond — celui de l'entrée qui le décrit dans VOTRE fichier, si : `mmConfigs: {bob: {path: …, yolo: true}}` laisse s'exécuter les appels de bob alors que les vôtres demandent toujours (un codeur à qui l'on confie les modifications une fois le passage de main approuvé), `yolo: false` demande pour chacun de ses appels même quand les vôtres s'exécutent librement. Les outils de bob s'appellent `bob/<outil>`, donc autoriser le `bash` de votre agent « pour cette session » n'autorise pas celui de bob. Voir [Le mode yolo et les permissions](yolo-and-permissions.md).
14	14
15	15	La réponse est une paire de messages. Elle entre dans votre historique comme un message utilisateur (`[asked bob (fournisseur/modèle): …]`) suivi d'un message de l'assistant (`[bob's answer]` et le texte). Un seul message aurait été plus simple, mais votre question suivante est aussi un message utilisateur, et plusieurs templates de chat (ceux de Gemma, de Mistral) refusent deux messages utilisateur à la suite. Les marques disent qui a dit quoi, pour que votre modèle ne prenne pas la réponse de bob pour la sienne. La réponse est plafonnée comme la sortie d'un outil, à `maxOutput` caractères : elle atterrit dans la fenêtre de votre modèle.
16	16
@@ -20,11 +20,13 @@
20	20
21	21	L'enfant est protégé de ce qui est destiné à son parent. Des variables comme `AGENT_MODEL`, `AGENT_PROVIDER` ou `AGENT_BASE_URL` surchargent une configuration ; héritées par bob, elles en feraient silencieusement une copie de vous. Elles sont retirées de son environnement. Bob tourne aussi avec `AGENT_SESSIONS=off` : il travaille dans votre projet, et ses fichiers de session apparaîtraient sinon dans vos `/sessions` et `/resume`.
22	22
23		-Les chaînes s'arrêtent. `/ask` est une commande tapée par une personne ; aucun modèle ne peut l'appeler, donc aucun agent ne boucle tout seul. Une personne pourrait quand même taper `/ask` dans un agent lui-même interrogé, alors chaque enfant connaît sa profondeur (`MM_ASK_DEPTH`) : votre agent peut interroger bob, bob peut interroger riker, riker ne peut interroger personne.
	23	+Votre modèle peut aussi décider : `ask_agent`. Dès que `mmConfigs` est renseigné, votre agent reçoit un outil intégré qui interroge l'un des agents et renvoie sa réponse comme résultat de l'outil. Sa description liste les agents avec le rôle de chacun — la `description` de l'entrée, à défaut l'`acp.title` de l'agent — et c'est tout ce dont le modèle dispose pour choisir : une description dit donc quand appeler l'agent, pas qui il est. L'outil s'appuie sur le même pool et le même protocole que `/ask`, à l'intérieur du tour : le texte, les pensées et les appels d'outils de l'agent défilent dans votre façade au fur et à mesure, et la fenêtre le nomme pendant qu'il travaille — son titre et son modèle dans l'en-tête, `asked by` votre agent, sa réponse étiquetée à son nom. L'appel lui-même est soumis comme `bash` : avec `yolo: false`, vous voyez le prompt écrit par votre modèle avant qu'il parte. La réponse est un résultat d'outil, pas une paire `/ask` dans l'historique : votre modèle la lit et poursuit dans le même tour — la rapporter, la vérifier, confier l'étape suivante à un autre agent.
	24	+
	25	+Les chaînes s'arrêtent. Un modèle qui appelle `ask_agent` depuis un agent lui-même interrogé pourrait continuer à interroger ; chaque enfant connaît donc sa profondeur (`MM_ASK_DEPTH`) : votre agent peut interroger bob, bob peut interroger riker, riker ne peut interroger personne — que ce soit par un `/ask` tapé ou par `ask_agent`.
24	26
25	27	La même mécanique répond aux scripts. `mm --ask <agent>` et `mm --ask-with-context <agent>` sont les commandes slash de ce qui ne sait que lancer une commande — une skill, un script. Ils démarrent le même enfant en ACP, avec la même protection de l'environnement et la même limite de profondeur, mais la réponse va sur stdout et tout le reste sur stderr, pour que l'appelant récupère la réponse seule. mm exporte `MM_BIN` et `MM_CONFIG` vers les commandes de son outil `bash`, donc une skill appelle « ce mm, avec cette configuration » sans connaître aucun des deux chemins. Deux choses diffèrent des commandes slash, parce que l'appelant est une commande et non une personne. Les appels d'outils de l'agent suivent le `yolo` de la configuration appelante : autorisés quand il est activé — la personne a déjà validé la commande `mm --ask` elle-même —, refusés quand il est désactivé, puisque stdin portait la question et que personne n'est là pour répondre. Et `mm --ask` surveille son processus parent : l'outil `bash` tue `bash` quand son budget est écoulé, pas les enfants de bash, et une demande orpheline laissait son agent tourner — et écrire des fichiers — alors que plus personne n'attendait.
26	28
27		-Le temps est le point faible. Un modèle local peut mettre une minute à répondre, et une commande `bash` disposait de 30 secondes ; `bashTimeout` règle désormais ce budget. Le watchdog de l'agent qui pose la question continue aussi de compter pendant qu'une commande tourne (ticket 57), il faut donc le relever aussi tant que ce ticket n'est pas corrigé.
	29	+Le temps est le point faible. Un modèle local peut mettre une minute à répondre, et une commande `bash` disposait de 30 secondes ; `bashTimeout` règle désormais ce budget. Le watchdog de l'agent qui pose la question continue aussi de compter pendant qu'une commande tourne (ticket 57), il faut donc le relever aussi tant que ce ticket n'est pas corrigé. `ask_agent` fait mieux parce qu'il voit l'agent travailler : chaque événement que l'agent diffuse — du texte, une pensée, un appel d'outil — compte comme un signe de vie pour le watchdog de votre agent. Seul un long silence termine encore le tour : un agent qui charge un gros modèle, ou qui lit un long premier prompt ; `watchdogTimeout` doit couvrir cette durée.
28	30
29	31	## Alternatives écartées
30	32
@@ -32,6 +34,7 @@
32	34	- Un second moteur dans le même processus. Rapide, sans processus — au prix de transformer la configuration globale en configuration par agent dans tout le code.
33	35	- Faire répondre le modèle courant tout de suite avec l'apport de bob. L'utilisateur a choisi autrement : la réponse de bob est affichée et gardée, et vous décidez de la question suivante.
34	36	- Garder la conversation de bob d'une demande à l'autre. Deux conversations qui évoluent en parallèle, dont une invisible, sont plus difficiles à suivre qu'une transcription explicite envoyée quand on la demande.
	37	+- Des skills qui lancent `mm --ask` pour le modèle. Ça marche — une skill par passage de main, la commande dans son texte — et `mm --ask` reste pour les scripts. Mais le travail de l'agent vous parvient comme la sortie d'une commande `bash` : pas de nom dans l'en-tête, pas d'étiquette sur sa réponse, ses appels d'outils en lignes de texte. Et un petit coordinateur doit recopier une longue commande à l'identique : mesuré avec Gemma 4 E4B, il a oublié les guillemets et un préfixe `AGENT_YOLO=true`, si bien que le codeur appelé ne pouvait pas écrire. Un appel d'outil avec un `agent` et un `prompt` n'a rien à recopier.
35	38	- Seulement un `/ask <nom>` générique, y compris dans les éditeurs. Le menu `/` d'un éditeur complète un nom de commande, jamais son argument ; une commande par agent est la seule façon pour que le menu liste les agents.
36	39
37	40	## Lien avec le reste

  ## De quoi s'agit-il ?
--`/ask-bob <prompt>` permet à l'agent avec qui vous parlez de consulter un autre agent mm : un autre modèle, un autre prompt système, d'autres outils et skills. La réponse de bob est affichée, puis gardée dans votre conversation pour que votre propre modèle s'en serve à votre question suivante. Cette page explique comment c'est construit et pourquoi.
++`/ask-bob <prompt>` permet à l'agent avec qui vous parlez de consulter un autre agent mm : un autre modèle, un autre prompt système, d'autres outils et skills. La réponse de bob est affichée, puis gardée dans votre conversation pour que votre propre modèle s'en serve à votre question suivante. L'outil `ask_agent` permet à votre modèle de faire de même de lui-même, quand une demande correspond au rôle d'un agent. Cette page explique comment c'est construit et pourquoi.
  ## Pourquoi c'est conçu ainsi
  **Les deux parlent ACP.** mm parle déjà l'Agent Client Protocol comme serveur, pour les éditeurs. Interroger bob fait de l'agent qui pose la question un *client* ACP de son enfant. Le protocole apporte gratuitement ce que lire un terminal n'aurait jamais donné : la réponse de bob sous forme de texte, ses appels d'outils comme des événements structurés, ses demandes de permission comme des requêtes auxquelles on peut répondre, et une façon standard d'annuler. Le serveur ACP de mm n'appelle que deux méthodes du client — les mises à jour de session et les demandes de permission — donc le côté client est petit ; les requêtes de fichiers et de terminal sont refusées comme absentes.
--**Les permissions de bob, c'est vous qui les donnez.** Bob est lancé avec `AGENT_YOLO=false` : chaque appel qu'il filtrerait devient une demande de permission adressée à votre agent, et c'est VOTRE `yolo` qui décide : activé, l'appel s'exécute ; désactivé, la question va à la façade que vous utilisez — le dialogue de l'éditeur, la zone de la fenêtre, l'invite `🔐` du mode ligne — exactement comme pour les outils de votre propre agent à cet endroit. Le `yolo` du fichier de bob ne compte pas tant qu'il vous répond. Les outils de bob s'appellent `bob/<outil>`, donc autoriser le `bash` de votre agent « pour cette session » n'autorise pas celui de bob. Voir [Le mode yolo et les permissions](yolo-and-permissions.md).
++**Les permissions de bob, c'est vous qui les donnez.** Bob est lancé avec `AGENT_YOLO=false` : chaque appel qu'il filtrerait devient une demande de permission adressée à votre agent, et c'est VOTRE `yolo` qui décide : activé, l'appel s'exécute ; désactivé, la question va à la façade que vous utilisez — le dialogue de l'éditeur, la zone de la fenêtre, l'invite `🔐` du mode ligne — exactement comme pour les outils de votre propre agent à cet endroit. Le `yolo` du fichier de bob ne compte pas tant qu'il vous répond — celui de l'entrée qui le décrit dans VOTRE fichier, si : `mmConfigs: {bob: {path: …, yolo: true}}` laisse s'exécuter les appels de bob alors que les vôtres demandent toujours (un codeur à qui l'on confie les modifications une fois le passage de main approuvé), `yolo: false` demande pour chacun de ses appels même quand les vôtres s'exécutent librement. Les outils de bob s'appellent `bob/<outil>`, donc autoriser le `bash` de votre agent « pour cette session » n'autorise pas celui de bob. Voir [Le mode yolo et les permissions](yolo-and-permissions.md).
  **La réponse est une paire de messages.** Elle entre dans votre historique comme un message utilisateur (`[asked bob (fournisseur/modèle): …]`) suivi d'un message de l'assistant (`[bob's answer]` et le texte). Un seul message aurait été plus simple, mais votre question suivante est aussi un message utilisateur, et plusieurs templates de chat (ceux de Gemma, de Mistral) refusent deux messages utilisateur à la suite. Les marques disent qui a dit quoi, pour que votre modèle ne prenne pas la réponse de bob pour la sienne. La réponse est plafonnée comme la sortie d'un outil, à `maxOutput` caractères : elle atterrit dans la fenêtre de votre modèle.
  **L'enfant est protégé de ce qui est destiné à son parent.** Des variables comme `AGENT_MODEL`, `AGENT_PROVIDER` ou `AGENT_BASE_URL` surchargent une configuration ; héritées par bob, elles en feraient silencieusement une copie de vous. Elles sont retirées de son environnement. Bob tourne aussi avec `AGENT_SESSIONS=off` : il travaille dans votre projet, et ses fichiers de session apparaîtraient sinon dans vos `/sessions` et `/resume`.
--**Les chaînes s'arrêtent.** `/ask` est une commande tapée par une personne ; aucun modèle ne peut l'appeler, donc aucun agent ne boucle tout seul. Une personne pourrait quand même taper `/ask` dans un agent lui-même interrogé, alors chaque enfant connaît sa profondeur (`MM_ASK_DEPTH`) : votre agent peut interroger bob, bob peut interroger riker, riker ne peut interroger personne.
++**Votre modèle peut aussi décider : `ask_agent`.** Dès que `mmConfigs` est renseigné, votre agent reçoit un outil intégré qui interroge l'un des agents et renvoie sa réponse comme résultat de l'outil. Sa description liste les agents avec le rôle de chacun — la `description` de l'entrée, à défaut l'`acp.title` de l'agent — et c'est tout ce dont le modèle dispose pour choisir : une description dit donc quand appeler l'agent, pas qui il est. L'outil s'appuie sur le même pool et le même protocole que `/ask`, à l'intérieur du tour : le texte, les pensées et les appels d'outils de l'agent défilent dans votre façade au fur et à mesure, et la fenêtre le nomme pendant qu'il travaille — son titre et son modèle dans l'en-tête, `asked by` votre agent, sa réponse étiquetée à son nom. L'appel lui-même est soumis comme `bash` : avec `yolo: false`, vous voyez le prompt écrit par votre modèle avant qu'il parte. La réponse est un résultat d'outil, pas une paire `/ask` dans l'historique : votre modèle la lit et poursuit dans le même tour — la rapporter, la vérifier, confier l'étape suivante à un autre agent.
++
++**Les chaînes s'arrêtent.** Un modèle qui appelle `ask_agent` depuis un agent lui-même interrogé pourrait continuer à interroger ; chaque enfant connaît donc sa profondeur (`MM_ASK_DEPTH`) : votre agent peut interroger bob, bob peut interroger riker, riker ne peut interroger personne — que ce soit par un `/ask` tapé ou par `ask_agent`.
  **La même mécanique répond aux scripts.** `mm --ask <agent>` et `mm --ask-with-context <agent>` sont les commandes slash de ce qui ne sait que lancer une commande — une skill, un script. Ils démarrent le même enfant en ACP, avec la même protection de l'environnement et la même limite de profondeur, mais la réponse va sur stdout et tout le reste sur stderr, pour que l'appelant récupère la réponse seule. mm exporte `MM_BIN` et `MM_CONFIG` vers les commandes de son outil `bash`, donc une skill appelle « ce mm, avec cette configuration » sans connaître aucun des deux chemins. Deux choses diffèrent des commandes slash, parce que l'appelant est une commande et non une personne. Les appels d'outils de l'agent suivent le `yolo` de la configuration appelante : autorisés quand il est activé — la personne a déjà validé la commande `mm --ask` elle-même —, refusés quand il est désactivé, puisque stdin portait la question et que personne n'est là pour répondre. Et `mm --ask` surveille son processus parent : l'outil `bash` tue `bash` quand son budget est écoulé, pas les enfants de bash, et une demande orpheline laissait son agent tourner — et écrire des fichiers — alors que plus personne n'attendait.
--**Le temps est le point faible.** Un modèle local peut mettre une minute à répondre, et une commande `bash` disposait de 30 secondes ; `bashTimeout` règle désormais ce budget. Le watchdog de l'agent qui pose la question continue aussi de compter pendant qu'une commande tourne (ticket 57), il faut donc le relever aussi tant que ce ticket n'est pas corrigé.
++**Le temps est le point faible.** Un modèle local peut mettre une minute à répondre, et une commande `bash` disposait de 30 secondes ; `bashTimeout` règle désormais ce budget. Le watchdog de l'agent qui pose la question continue aussi de compter pendant qu'une commande tourne (ticket 57), il faut donc le relever aussi tant que ce ticket n'est pas corrigé. `ask_agent` fait mieux parce qu'il voit l'agent travailler : chaque événement que l'agent diffuse — du texte, une pensée, un appel d'outil — compte comme un signe de vie pour le watchdog de votre agent. Seul un long silence termine encore le tour : un agent qui charge un gros modèle, ou qui lit un long premier prompt ; `watchdogTimeout` doit couvrir cette durée.
  ## Alternatives écartées
  - **Un second moteur dans le même processus.** Rapide, sans processus — au prix de transformer la configuration globale en configuration par agent dans tout le code.
  - **Faire répondre le modèle courant tout de suite avec l'apport de bob.** L'utilisateur a choisi autrement : la réponse de bob est affichée et gardée, et vous décidez de la question suivante.
  - **Garder la conversation de bob d'une demande à l'autre.** Deux conversations qui évoluent en parallèle, dont une invisible, sont plus difficiles à suivre qu'une transcription explicite envoyée quand on la demande.
++- **Des skills qui lancent `mm --ask` pour le modèle.** Ça marche — une skill par passage de main, la commande dans son texte — et `mm --ask` reste pour les scripts. Mais le travail de l'agent vous parvient comme la sortie d'une commande `bash` : pas de nom dans l'en-tête, pas d'étiquette sur sa réponse, ses appels d'outils en lignes de texte. Et un petit coordinateur doit recopier une longue commande à l'identique : mesuré avec Gemma 4 E4B, il a oublié les guillemets et un préfixe `AGENT_YOLO=true`, si bien que le codeur appelé ne pouvait pas écrire. Un appel d'outil avec un `agent` et un `prompt` n'a rien à recopier.
  - **Seulement un `/ask <nom>` générique, y compris dans les éditeurs.** Le menu `/` d'un éditeur complète un nom de commande, jamais son argument ; une commande par agent est la seule façon pour que le menu liste les agents.
  ## Lien avec le reste

modified docs/fr/how-to/ask-another-agent-from-a-skill.md +24 -5 Viewed

@@ -1,6 +1,6 @@
1	1	# Comment interroger un autre agent depuis une skill ou un script
2	2
3		-Ce guide montre comment faire poser une question à un autre agent mm par une skill — ou par n'importe quel script shell — et se servir de sa réponse. Il suppose que les agents sont déjà déclarés sous `mmConfigs` (voir [comment interroger un autre agent](ask-another-agent.md)).
	3	+Ce guide montre comment faire poser une question à un autre agent mm par une skill — ou par n'importe quel script shell — et se servir de sa réponse. Il suppose que les agents sont déjà déclarés sous `mmConfigs` (voir [comment interroger un autre agent](ask-another-agent.md)). Pour que votre modèle confie du travail à un autre agent de lui-même, l'[outil `ask_agent`](let-the-agent-call-other-agents.md) est la voie la plus simple : aucune commande à recopier, et la fenêtre montre quel agent travaille. Une skill sert pour une procédure figée, un script, ou plusieurs agents en une seule commande.
4	4
5	5	## Étapes
6	6
@@ -25,11 +25,30 @@ Ce guide montre comment faire poser une question à un autre agent mm par une sk
25	25
26	26	C'est le modèle qui écrit ce résumé lui-même : une commande ne peut pas lire la conversation.
27	27
28		-3. Dites au modèle, dans la skill, de lancer la commande une seule fois et de présenter la réponse comme celle de l'autre agent. `demo-llmman/skills/` en contient trois exemples complets :
	28	+3. Dites au modèle, dans la skill, de lancer la commande une seule fois et de présenter la réponse comme celle de l'autre agent. Une skill complète (`skills/second-opinion/SKILL.md`) :
29	29
30		- - `delegate-to-jan` — une question déléguée à Jan ;
31		- - `second-opinion` — la conversation envoyée à un relecteur ;
32		- - `compare-agents` — la même question à Jan et à Lucy, en une seule commande.
	30	+ ```markdown
	31	+ ---
	32	+ name: second-opinion
	33	+ description: Get a second opinion from the reviewer agent on a claim or an answer from this conversation.
	34	+ keywords: second opinion, review, check, deuxième avis, vérifie, relis
	35	+ ---
	36	+
	37	+ # Second opinion
	38	+
	39	+ Call your `bash` tool ONCE with this command, the conversation summarised in English above the `---` line, the question below it:
	40	+
	41	+ "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
	42	+ User: <the claim>
	43	+ Assistant: <your answer, if any>
	44	+ ---
	45	+ Is this right? Correct it if not.
	46	+ CONTEXT
	47	+
	48	+ What it prints is the reviewer's answer. Report it, starting with "The reviewer says:"; never answer in its place. If it prints `[ask: …]`, tell the user that line.
	49	+ ```
	50	+
	51	+ Gardez une telle commande courte : un petit modèle recopie une longue commande de façon inexacte (guillemets, préfixes).
33	52
34	53	4. Relevez les délais dans la configuration de l'agent qui pose la question. Un modèle local peut mettre une minute à répondre, et les deux délais par défaut sont bien en dessous :
35	54

  # Comment interroger un autre agent depuis une skill ou un script
--Ce guide montre comment faire poser une question à un autre agent mm par une skill — ou par n'importe quel script shell — et se servir de sa réponse. Il suppose que les agents sont déjà déclarés sous `mmConfigs` (voir [comment interroger un autre agent](ask-another-agent.md)).
++Ce guide montre comment faire poser une question à un autre agent mm par une skill — ou par n'importe quel script shell — et se servir de sa réponse. Il suppose que les agents sont déjà déclarés sous `mmConfigs` (voir [comment interroger un autre agent](ask-another-agent.md)). Pour que votre modèle confie du travail à un autre agent de lui-même, l'[outil `ask_agent`](let-the-agent-call-other-agents.md) est la voie la plus simple : aucune commande à recopier, et la fenêtre montre quel agent travaille. Une skill sert pour une procédure figée, un script, ou plusieurs agents en une seule commande.
  ## Étapes
     C'est le modèle qui écrit ce résumé lui-même : une commande ne peut pas lire la conversation.
--3. Dites au modèle, dans la skill, de lancer la commande une seule fois et de présenter la réponse comme celle de l'autre agent. `demo-llmman/skills/` en contient trois exemples complets :
++3. Dites au modèle, dans la skill, de lancer la commande une seule fois et de présenter la réponse comme celle de l'autre agent. Une skill complète (`skills/second-opinion/SKILL.md`) :
--   - `delegate-to-jan` — une question déléguée à Jan ;
++   ```markdown
--   - `second-opinion` — la conversation envoyée à un relecteur ;
++   ---
--   - `compare-agents` — la même question à Jan et à Lucy, en une seule commande.
++   name: second-opinion
++   description: Get a second opinion from the reviewer agent on a claim or an answer from this conversation.
++   keywords: second opinion, review, check, deuxième avis, vérifie, relis
++   ---
++
++   # Second opinion
++
++   Call your `bash` tool ONCE with this command, the conversation summarised in English above the `---` line, the question below it:
++
++       "$MM_BIN" --ask-with-context reviewer <<'CONTEXT'
++       User: <the claim>
++       Assistant: <your answer, if any>
++       ---
++       Is this right? Correct it if not.
++       CONTEXT
++
++   What it prints is the reviewer's answer. Report it, starting with "The reviewer says:"; never answer in its place. If it prints `[ask: …]`, tell the user that line.
++   ```
++
++   Gardez une telle commande courte : un petit modèle recopie une longue commande de façon inexacte (guillemets, préfixes).
 . Relevez les délais dans la configuration de l'agent qui pose la question. Un modèle local peut mettre une minute à répondre, et les deux délais par défaut sont bien en dessous :

added docs/fr/how-to/let-the-agent-call-other-agents.md +73 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified docs/fr/reference/configuration.md +2 -2 Viewed

@@ -33,7 +33,7 @@
33	33	\| `tui` \| bool \| `false` \| Démarre dans le mode fenêtre unique sans l'option `-tui`. Retombe sur le mode ligne quand stdin ou stdout n'est pas un terminal ; ignoré avec `-acp`. \|
34	34	\| `yolo` \| booléen \| `true` \| `true` : les outils s'exécutent sans demander. `false` : chaque appel qui modifie quelque chose — `bash`, `write_file`, `edit_file`, `fetch_content` avec `output`, `rename` de `lsp`, `create`/`update`/`next`/`delete` de `plan` — attend la réponse de l'utilisateur dans toutes les façades (mode ligne, fenêtre, éditeur), de même que chaque outil MCP, quoi que dise `mcp.permissions`. Réponses : autoriser une fois, autoriser cet outil pour la session, refuser cet appel, jamais (cet outil, pour la session). `read_file`, `read_skill`, `fetch_content` sans `output` et les actions de navigation de `lsp` ne demandent jamais. Avec `-p` et `mm --ask`, personne ne peut répondre : ces appels sont refusés. Un agent lancé par `/ask` tourne avec `AGENT_YOLO=false` et soumet ses appels à l'agent qui l'interroge, dont le `yolo` décide. Surchargée par `AGENT_YOLO`. `bashTool`, `editTools`, `fetchContentTool` décident toujours quels outils existent. Voir [Confirmer les appels d'outils](../how-to/confirm-tool-calls.md). \|
35	35	\| `permissions` \| chaîne \| absente \| Obsolète, remplacée par `yolo`. `ask` = `yolo: false` (et l'emporte sur `yolo: true`) ; `auto` ne change rien. Les deux valeurs ajoutent un avertissement au démarrage. Doit valoir `auto` ou `ask`. \|
36		-\| `mmConfigs` \| dictionnaire nom → chemin \| aucun \| Les autres agents mm que celui-ci peut interroger. Chaque nom génère `/ask-<nom>` et `/ask-with-context-<nom>` (voir les [commandes slash](slash-commands.md#interroger-un-autre-agent)). Un chemin relatif l'est au dossier du fichier qui le déclare. Noms : lettres minuscules, chiffres et `-`, commençant par une lettre ou un chiffre, ne commençant pas par `with-context`. Un chemin dont le fichier n'existe pas donne un avertissement au démarrage, pas une erreur. \|
	36	+\| `mmConfigs` \| dictionnaire nom → chemin, ou nom → `{path, description, yolo}` \| aucun \| Les autres agents mm que celui-ci peut interroger. Chaque nom génère `/ask-<nom>` et `/ask-with-context-<nom>` (voir les [commandes slash](slash-commands.md#interroger-un-autre-agent)), et la liste déclare l'outil [`ask_agent`](tools.md#ask_agent), par lequel le modèle les appelle lui-même. La forme longue ajoute `description` (quand appeler cet agent ; affichée dans la description d'`ask_agent`, à défaut l'`acp.title` du fichier de l'agent) et `yolo` (décide des appels d'outils de cet agent quand il est interrogé, par `/ask`, `ask_agent` ou `mm --ask`, à la place du `yolo` de cet agent-ci : `true` ils s'exécutent, `false` chacun est demandé ; absent, le `yolo` de cet agent-ci décide). `path` ne doit pas être vide. Un chemin relatif l'est au dossier du fichier qui le déclare. Noms : lettres minuscules, chiffres et `-`, commençant par une lettre ou un chiffre, ne commençant pas par `with-context`. Un chemin dont le fichier n'existe pas donne un avertissement au démarrage, pas une erreur. \|
37	37
38	38	## Clés de `context`
39	39
@@ -124,7 +124,7 @@ Signalées sous la forme `[config error: <chemin>: <message>]`, code de sortie 1
124	124	\| `bashTimeout must be > 0` \| zéro ou négative \|
125	125	\| `mmConfigs: "Bob" is not a valid name (…)` \| un nom avec des majuscules, des espaces ou d'autres caractères, ou commençant par `-` \|
126	126	\| `mmConfigs: "with-context-x" is not a valid name (it would read as /ask-with-context-…)` \| un nom commençant par `with-context` \|
127		-\| `mmConfigs.<nom>: the path must not be empty` \| `<nom>: ""` \|
	127	+\| `mmConfigs.<nom>: the path must not be empty` \| `<nom>: ""`, ou une forme longue sans `path` \|
128	128	\| `unknown provider "x" (known: dmr, llamacpp, llmman, ollama)` \| Signalée par le moteur, sous la forme `[engine error: …]`. \|
129	129
130	130	Un avertissement au démarrage, et non une erreur, est affiché quand `context.enabled` vaut `true`, que la fenêtre est inconnue et que `context.maxMessages` vaut `0`, et quand le fichier pose la clé obsolète `permissions` (`permissions: ask is deprecated — use yolo: false instead …`).

  | `tui` | bool | `false` | Démarre dans le mode fenêtre unique sans l'option `-tui`. Retombe sur le mode ligne quand stdin ou stdout n'est pas un terminal ; ignoré avec `-acp`. |
  | `yolo` | booléen | `true` | `true` : les outils s'exécutent sans demander. `false` : chaque appel qui modifie quelque chose — `bash`, `write_file`, `edit_file`, `fetch_content` avec `output`, `rename` de `lsp`, `create`/`update`/`next`/`delete` de `plan` — attend la réponse de l'utilisateur dans toutes les façades (mode ligne, fenêtre, éditeur), de même que chaque outil MCP, quoi que dise `mcp.permissions`. Réponses : autoriser une fois, autoriser cet outil pour la session, refuser cet appel, jamais (cet outil, pour la session). `read_file`, `read_skill`, `fetch_content` sans `output` et les actions de navigation de `lsp` ne demandent jamais. Avec `-p` et `mm --ask`, personne ne peut répondre : ces appels sont refusés. Un agent lancé par `/ask` tourne avec `AGENT_YOLO=false` et soumet ses appels à l'agent qui l'interroge, dont le `yolo` décide. Surchargée par `AGENT_YOLO`. `bashTool`, `editTools`, `fetchContentTool` décident toujours quels outils existent. Voir [Confirmer les appels d'outils](../how-to/confirm-tool-calls.md). |
  | `permissions` | chaîne | absente | Obsolète, remplacée par `yolo`. `ask` = `yolo: false` (et l'emporte sur `yolo: true`) ; `auto` ne change rien. Les deux valeurs ajoutent un avertissement au démarrage. Doit valoir `auto` ou `ask`. |
--| `mmConfigs` | dictionnaire nom → chemin | aucun | Les autres agents mm que celui-ci peut interroger. Chaque nom génère `/ask-<nom>` et `/ask-with-context-<nom>` (voir les [commandes slash](slash-commands.md#interroger-un-autre-agent)). Un chemin relatif l'est au dossier du fichier qui le déclare. Noms : lettres minuscules, chiffres et `-`, commençant par une lettre ou un chiffre, ne commençant pas par `with-context`. Un chemin dont le fichier n'existe pas donne un avertissement au démarrage, pas une erreur. |
++| `mmConfigs` | dictionnaire nom → chemin, ou nom → `{path, description, yolo}` | aucun | Les autres agents mm que celui-ci peut interroger. Chaque nom génère `/ask-<nom>` et `/ask-with-context-<nom>` (voir les [commandes slash](slash-commands.md#interroger-un-autre-agent)), et la liste déclare l'outil [`ask_agent`](tools.md#ask_agent), par lequel le modèle les appelle lui-même. La forme longue ajoute `description` (quand appeler cet agent ; affichée dans la description d'`ask_agent`, à défaut l'`acp.title` du fichier de l'agent) et `yolo` (décide des appels d'outils de cet agent quand il est interrogé, par `/ask`, `ask_agent` ou `mm --ask`, à la place du `yolo` de cet agent-ci : `true` ils s'exécutent, `false` chacun est demandé ; absent, le `yolo` de cet agent-ci décide). `path` ne doit pas être vide. Un chemin relatif l'est au dossier du fichier qui le déclare. Noms : lettres minuscules, chiffres et `-`, commençant par une lettre ou un chiffre, ne commençant pas par `with-context`. Un chemin dont le fichier n'existe pas donne un avertissement au démarrage, pas une erreur. |
  ## Clés de `context`
  | `bashTimeout must be > 0` | zéro ou négative |
  | `mmConfigs: "Bob" is not a valid name (…)` | un nom avec des majuscules, des espaces ou d'autres caractères, ou commençant par `-` |
  | `mmConfigs: "with-context-x" is not a valid name (it would read as /ask-with-context-…)` | un nom commençant par `with-context` |
--| `mmConfigs.<nom>: the path must not be empty` | `<nom>: ""` |
++| `mmConfigs.<nom>: the path must not be empty` | `<nom>: ""`, ou une forme longue sans `path` |
  | `unknown provider "x" (known: dmr, llamacpp, llmman, ollama)` | Signalée par le moteur, sous la forme `[engine error: …]`. |
  Un avertissement au démarrage, et non une erreur, est affiché quand `context.enabled` vaut `true`, que la fenêtre est inconnue et que `context.maxMessages` vaut `0`, et quand le fichier pose la clé obsolète `permissions` (`permissions: ask is deprecated — use yolo: false instead …`).

modified docs/fr/reference/tools.md +22 -0 Viewed

@@ -200,6 +200,28 @@ Déclaré seulement avec `fetchContentTool: true`. Télécharge une page web et
200	200	\| `2` \| `input` \| Hôte injoignable, délai dépassé, statut HTTP ≥ 300 après redirections, plus de 10 redirections, page interdite par le robots.txt ou robots.txt illisible. \|
201	201	\| `3` \| `usage` \| `url` vide ou illisible, schéma autre que `http`/`https`, valeur de `tables` inconnue, `baseUrl` non absolue. \|
202	202
	203	+## `ask_agent`
	204	+
	205	+Déclaré quand `mmConfigs` nomme au moins un agent. Confie une tâche à l'un d'eux et renvoie sa réponse comme résultat de l'outil : c'est le modèle qui décide quand, d'après les descriptions des agents. Même mécanique que `/ask` (paquet `internal/ask`) : l'agent tourne comme un `mm -acp` enfant, démarré au premier appel puis réutilisé, avec une session neuve à chaque appel.
	206	+
	207	+\| Champ \| Type \| Défaut \| Description \|
	208	+\|-------\|------\|--------\|-------------\|
	209	+\| `agent` \| chaîne \| — \| Un nom de `mmConfigs`. \|
	210	+\| `prompt` \| chaîne \| — \| La tâche, complète et autonome. \|
	211	+\| `with_context` \| booléen \| `false` \| Envoie cette conversation avant le prompt : l'historique au début du tour (questions, réponses, une ligne par appel d'outil, jamais les sorties d'outils), limité à `maxOutput` caractères, les plus récents gardés. \|
	212	+
	213	+\| Aspect \| Comportement \|
	214	+\|--------\|--------------\|
	215	+\| Description \| Un paragraphe fixe, puis `Agents:` et une ligne ` <nom> — <rôle>` par agent, triés par nom. `<rôle>` est la `description` de l'entrée, sinon l'`acp.title` du fichier de l'agent (s'il n'est pas celui intégré), sinon `(no description)`. \|
	216	+\| Permission \| L'appel lui-même est soumis comme `bash` : demandé quand `yolo: false`. \|
	217	+\| Appels de l'agent interrogé \| Décidés par le `yolo` de son entrée dans `mmConfigs` s'il est fixé (`true` exécutés, `false` demandés), sinon par le `yolo` de cet agent. \|
	218	+\| Répertoire de travail \| Le répertoire du processus dans le terminal et la fenêtre ; le `cwd` de la session en ACP. \|
	219	+\| Affichage \| Le texte, les pensées et les appels d'outils de l'agent interrogé défilent dans le tour, ses appels titrés `<agent> · <titre>`. La fenêtre le nomme pendant qu'il travaille : en-tête `mm [<acp.title>] · <modèle> @ <fournisseur> · asked by <cet agent>`, sa réponse sous `‣ mm [<acp.title>]` (son nom dans `mmConfigs` s'il n'a pas de titre). Mode ligne : `🗣 ask_agent: <agent> (<fournisseur>/<modèle>) — <première ligne du prompt>`, puis la sortie de l'agent. \|
	220	+\| Chien de garde \| Chaque événement de l'agent interrogé (texte, pensée, appel d'outil, permission répondue) compte comme un signe de vie pour le chien de garde de cet agent. Un silence plus long que `watchdogTimeout` — un modèle qui se charge, un long prompt en lecture — termine quand même le tour. \|
	221	+\| Résultat \| La réponse, tronquée à `maxOutput`. La sortie de l'appel lui-même dans la fenêtre et l'éditeur est `<agent> answered (N characters)` : la réponse a déjà défilé. Pas ajoutée à l'historique comme un échange `/ask` : c'est un résultat d'outil. \|
	222	+\| Erreurs \| `[ask_agent: unknown agent "x" — agents: a, b]` ; `[ask_agent: the prompt is empty — say what <agent> must do]` ; `[ask_agent: <agent> failed: <raison>]` ; `[ask_agent: <agent> gave no answer]` ; une exécution annulée ou interrompue renvoie ce qui a été répondu, puis `[ask_agent: <agent> stopped before finishing: <raison>]`. \|
	223	+\| Profondeur \| Un agent interrogé peut lui-même avoir des `mmConfigs` et appeler `ask_agent`, jusqu'à deux niveaux (`MM_ASK_DEPTH`) ; au-delà, l'appel échoue avec le message de profondeur. \|
	224	+
203	225	## Détection de boucle
204	226
205	227	Chaque outil enregistre `(outil, entrée, sortie)` dans le détecteur de boucle après chaque appel.

  | `2` | `input` | Hôte injoignable, délai dépassé, statut HTTP ≥ 300 après redirections, plus de 10 redirections, page interdite par le robots.txt ou robots.txt illisible. |
  | `3` | `usage` | `url` vide ou illisible, schéma autre que `http`/`https`, valeur de `tables` inconnue, `baseUrl` non absolue. |
++## `ask_agent`
++
++Déclaré quand `mmConfigs` nomme au moins un agent. Confie une tâche à l'un d'eux et renvoie sa réponse comme résultat de l'outil : c'est le modèle qui décide quand, d'après les descriptions des agents. Même mécanique que `/ask` (paquet `internal/ask`) : l'agent tourne comme un `mm -acp` enfant, démarré au premier appel puis réutilisé, avec une session neuve à chaque appel.
++
++| Champ | Type | Défaut | Description |
++|-------|------|--------|-------------|
++| `agent` | chaîne | — | Un nom de `mmConfigs`. |
++| `prompt` | chaîne | — | La tâche, complète et autonome. |
++| `with_context` | booléen | `false` | Envoie cette conversation avant le prompt : l'historique au début du tour (questions, réponses, une ligne par appel d'outil, jamais les sorties d'outils), limité à `maxOutput` caractères, les plus récents gardés. |
++
++| Aspect | Comportement |
++|--------|--------------|
++| Description | Un paragraphe fixe, puis `Agents:` et une ligne `  <nom> — <rôle>` par agent, triés par nom. `<rôle>` est la `description` de l'entrée, sinon l'`acp.title` du fichier de l'agent (s'il n'est pas celui intégré), sinon `(no description)`. |
++| Permission | L'appel lui-même est soumis comme `bash` : demandé quand `yolo: false`. |
++| Appels de l'agent interrogé | Décidés par le `yolo` de son entrée dans `mmConfigs` s'il est fixé (`true` exécutés, `false` demandés), sinon par le `yolo` de cet agent. |
++| Répertoire de travail | Le répertoire du processus dans le terminal et la fenêtre ; le `cwd` de la session en ACP. |
++| Affichage | Le texte, les pensées et les appels d'outils de l'agent interrogé défilent dans le tour, ses appels titrés `<agent> · <titre>`. La fenêtre le nomme pendant qu'il travaille : en-tête `mm [<acp.title>] · <modèle> @ <fournisseur> · asked by <cet agent>`, sa réponse sous `‣ mm [<acp.title>]` (son nom dans `mmConfigs` s'il n'a pas de titre). Mode ligne : `🗣 ask_agent: <agent> (<fournisseur>/<modèle>) — <première ligne du prompt>`, puis la sortie de l'agent. |
++| Chien de garde | Chaque événement de l'agent interrogé (texte, pensée, appel d'outil, permission répondue) compte comme un signe de vie pour le chien de garde de cet agent. Un silence plus long que `watchdogTimeout` — un modèle qui se charge, un long prompt en lecture — termine quand même le tour. |
++| Résultat | La réponse, tronquée à `maxOutput`. La sortie de l'appel lui-même dans la fenêtre et l'éditeur est `<agent> answered (N characters)` : la réponse a déjà défilé. Pas ajoutée à l'historique comme un échange `/ask` : c'est un résultat d'outil. |
++| Erreurs | `[ask_agent: unknown agent "x" — agents: a, b]` ; `[ask_agent: the prompt is empty — say what <agent> must do]` ; `[ask_agent: <agent> failed: <raison>]` ; `[ask_agent: <agent> gave no answer]` ; une exécution annulée ou interrompue renvoie ce qui a été répondu, puis `[ask_agent: <agent> stopped before finishing: <raison>]`. |
++| Profondeur | Un agent interrogé peut lui-même avoir des `mmConfigs` et appeler `ask_agent`, jusqu'à deux niveaux (`MM_ASK_DEPTH`) ; au-delà, l'appel échoue avec le message de profondeur. |
++
  ## Détection de boucle
  Chaque outil enregistre `(outil, entrée, sortie)` dans le détecteur de boucle après chaque appel.

modified internal/acp/ask_test.go +1 -1 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/agent/ask.go +1 -47 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/agent/ask_test.go +1 -1 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ask/cli.go +2 -1 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ask/client.go +22 -4 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added internal/ask/linesink.go +60 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ask/pool_test.go +24 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ask/run.go +4 -3 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ask/run_test.go +2 -2 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/config/agents.go +45 -6 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/config/agents_test.go +29 -2 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/config/config.go +6 -5 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added internal/engine/conversation.go +45 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/engine/engine.go +2 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/engine/engine_test.go +62 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added internal/tools/askagent.go +205 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added internal/tools/askagent_test.go +166 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/tui/ask.go +3 -5 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/tui/ask_test.go +2 -2 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/tui/sink.go +21 -1 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified internal/ui/ui.go +12 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified main.go +9 -3 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/README.en.md +23 -34 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/README.md +23 -34 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/agent.homer.yaml +31 -18 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/agent.milo.yaml +29 -25 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/agent.riker.yaml +99 -75 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/bin/check.sh +0 -24 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/bin/implement.sh +0 -34 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/bin/specify.sh +0 -29 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/go.mod +1 -1 Viewed

@@ -1,3 +1,3 @@
1		-module notes
	1	+module hello-world-json
2	2
3	3	go 1.27

@@ -1,3 +1,3 @@
1	-module notes	1	+module hello-world-json
2		2
3	go 1.27	3	go 1.27

added mini-mes/riker/handlers.go +28 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/handlers_test.go +55 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/main.go +30 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/main_test.go +29 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

modified mini-mes/riker/skills-homer/implement-spec/SKILL.md +2 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/skills-homer/lsp-navigation/SKILL.md +45 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/skills/build-feature/SKILL.md +0 -30 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/skills/check-against-spec/SKILL.md +0 -21 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/skills/implement/SKILL.md +0 -26 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/skills/specify/SKILL.md +0 -37 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/specs/change-port-7070.spec.md +29 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.brief.md +0 -7 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.homer.log +0 -9 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.homer.out +0 -6 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.milo.log +0 -2 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.milo.out +0 -67 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

deleted mini-mes/riker/specs/crud-notes-webapp.spec.md +0 -67 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

added mini-mes/riker/specs/hello-world-json.spec.md +41 -0 Viewed

Large diff collapsed to keep the page fast — load it when you need it.

mini mes team #25