bots-garden/mini-me · bbcc277

modified .tickets/issues/0030-how-to-use-mini-me-with-claude.yaml +12 -4 Viewed

@@ -1,13 +1,14 @@
1	1	# Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
2	2	id: 30
3	3	title: How to use Mini Me with Claude
4		-state: open
	4	+state: closed
5	5	author:
6	6	name: k33g
7	7	email: ph.charriere@gmail.com
8	8	createdAt: 2026-09-21T04:00:56.971Z
9		-updatedAt: 2026-10-06T04:00:56.602Z
10		-labels: []
	9	+updatedAt: 2026-10-14T11:24:46.703Z
	10	+labels:
	11	+ - wontfix
11	12	epic: Providers (LLM Engine)
12	13	body: \|
13	14	## Analysis (Claude, 2026-09-21 — not implemented)
@@ -121,4 +122,11 @@ tasks:
121	122	name: k33g
122	123	email: ph.charriere@gmail.com
123	124	createdAt: 2026-09-21T05:45:00.000Z
124		-comments: []
	125	+comments:
	126	+ - id: 1
	127	+ author:
	128	+ name: k33g
	129	+ email: ph.charriere@gmail.com
	130	+ createdAt: 2026-10-14T11:24:35.367Z
	131	+ body: \|
	132	+ will not be implemented

  # Managed by IssueSpec. Hand edits are welcome; keep the schema valid.
  id: 30
  title: How to use Mini Me with Claude
--state: open
++state: closed
  author:
    name: k33g
    email: ph.charriere@gmail.com
  createdAt: 2026-09-21T04:00:56.971Z
--updatedAt: 2026-10-06T04:00:56.602Z
++updatedAt: 2026-10-14T11:24:46.703Z
--labels: []
++labels:
++  - wontfix
  epic: Providers (LLM Engine)
  body: |
    ## Analysis (Claude, 2026-09-21 — not implemented)
        name: k33g
        email: ph.charriere@gmail.com
      createdAt: 2026-09-21T05:45:00.000Z
--comments: []
++comments:
++  - id: 1
++    author:
++      name: k33g
++      email: ph.charriere@gmail.com
++    createdAt: 2026-10-14T11:24:35.367Z
++    body: |
++      will not be implemented

modified .tickets/issues/0071-mini-me-as-a-sdk.yaml +92 -2 Viewed

@@ -6,11 +6,101 @@ author:
6	6	name: k33g
7	7	email: ph.charriere@gmail.com
8	8	createdAt: 2026-10-02T05:32:33.878Z
9		-updatedAt: 2026-10-12T09:45:33.355Z
	9	+updatedAt: 2026-10-14T11:21:29.000Z
10	10	labels:
11	11	- priority::urgent
12	12	- kind::feature
13	13	epic: SDK
14		-body: ""
	14	+body: \|
	15	+ ## Proposal: what "Mini Me as an SDK" could look like
	16	+
	17	+ ### Goal
	18	+ Let a Go program embed mm's agent loop (provider registry, built-in tools, skills, MCP, consent, ask_user, sessions, compaction, structured output) without going through the CLI, and have the REPL, the TUI and ACP become three clients of that SDK.
	19	+
	20	+ ### Where we start (checked in the code on 2026-10-14)
	21	+ - Nothing can be imported today. The module is `module mm` and every package is under `internal/`.
	22	+ - The process holds global state, so you cannot run two agents in one process:
	23	+ - `config.Cfg` (31 references in `main.go`, about 50 more in `internal/`; `engine.New(ctx)` reads it and takes no config)
	24	+ - `ui.SetActive`/`ActiveSink` and `ui.Out`
	25	+ - `consent.SetPrompter`, `elicit.SetPrompter`
	26	+ - `engine.DeclareSkills` / `skills.Declare`
	27	+ - the package-level `planStore` in `tools`
	28	+ - The seams are already good. They are what the SDK would expose:
	29	+ - `ui.Sink` (+ `Elicitor`, `UsageSink`, `Speaker`): an event stream of a turn
	30	+ - `engine.Provider`: one implementation per wire protocol, plus a registry
	31	+ - tools are `ai.ToolRef` values built from `genkit.Genkit` + `detector.LoopDetector`
	32	+ - `store`/`session` for persistence; `ask.Runner` for agent-to-agent calls
	33	+ - `agent.RunStructuredPrompt` for typed output
	34	+
	35	+ ### Proposed public API (sketch)
	36	+ ```go
	37	+ import "<module>/mm"
	38	+
	39	+ a, err := mm.New(ctx,
	40	+ mm.WithProvider("llamacpp", mm.BaseURL("http://localhost:8080"), mm.Model("qwen3.8-27b")),
	41	+ mm.WithSystem(prompt), // or mm.FromYAML("agent.yaml"): same file as the CLI
	42	+ mm.WithTools(mm.Bash(), mm.ReadFile(), mm.EditFile(), mm.AskUser()),
	43	+ mm.WithSkills("./skills"),
	44	+ mm.WithMCP(servers...),
	45	+ mm.WithWorkDir(dir),
	46	+ mm.WithPermissions(mm.AskWith(func(ctx context.Context, c mm.ToolCall) mm.Decision { ... })),
	47	+ mm.WithElicitor(myFormUI), // ask_user answered by the host app
	48	+ )
	49	+ defer a.Close()
	50	+
	51	+ s := a.NewSession() // or a.ResumeSession(id) with a Store
	52	+ reply, err := s.Send(ctx, "fix the failing test") // blocking
	53	+ for ev, err := range s.Stream(ctx, "explain main.go") { // iter.Seq2[mm.Event, error]
	54	+ switch e := ev.(type) {
	55	+ case mm.TextDelta: ...
	56	+ case mm.Reasoning: ...
	57	+ case mm.ToolStart, mm.ToolEnd: ...
	58	+ case mm.Usage: ...
	59	+ case mm.Compacted: ...
	60	+ }
	61	+ }
	62	+
	63	+ // Typed output: generic wrapper around structured output
	64	+ type Verdict struct{ OK bool; Reason string }
	65	+ v, err := mm.Ask[Verdict](ctx, a, "does this diff break the API?")
	66	+
	67	+ // Custom tools: same loop detector, consent gate and events as the built-ins
	68	+ mm.Tool("get_ticket", "Read a ticket by id",
	69	+ func(ctx context.Context, tc mm.ToolContext, in struct{ ID int }) (Ticket, error) { ... })
	70	+
	71	+ // Agents as tools: in-process, instead of today's /ask subprocess
	72	+ reviewer, _ := mm.New(ctx, ...)
	73	+ a2, _ := mm.New(ctx, mm.WithTools(reviewer.AsTool("ask_reviewer", "...")))
	74	+ ```
	75	+ Extension points:
	76	+ - Hooks: `OnBeforeTool` (can veto or rewrite), `OnAfterTool`, `OnBeforeModel`, `OnTurnEnd`. Use them for audit, guardrails and tracing (today `trace:`).
	77	+ - `mm.RegisterProvider(p)`: for a protocol mm does not speak yet.
	78	+ - `mm.Store` interface: the file store (today's `store`) by default, plus an in-memory one for tests and servers.
	79	+
	80	+ ### Design rules I would hold to
	81	+ 1. Do not leak Genkit in the public types. Ticket 76 (v1.10 → v1.13.1) shows that Genkit changes. The SDK would expose its own types (`Message`, `ToolCall`, `Event`) and convert at the boundary. Genkit would stay an implementation detail.
	82	+ 2. No package-level state after phase 1. Everything hangs off `mm.Agent` / `mm.Session`, so two agents can run in one process (needed for agents as tools and for servers).
	83	+ 3. The SDK never writes to stdout/stdin. Output goes to events; questions go to `Permissions`/`Elicitor`. The terminal behaviour (tools that print themselves, `consent.Terminal`) becomes the REPL's own sink.
	84	+ 4. The YAML stays the reference. `mm.FromYAML` and the options build the same `Config`, so a demo agent from `demos/` can be loaded by a program unchanged.
	85	+ 5. Dogfooding is the proof. `main.go` + `internal/agent` + `internal/tui` + `internal/acp` are rewritten on top of `mm`. If the CLI cannot be built on the SDK, the SDK is not ready.
	86	+
	87	+ ### Plan in mergeable steps (CLI behaviour unchanged at each step)
	88	+ 1. Remove the globals. Add a `Runtime` (config, sink, prompters, plan store, declared skills) passed down explicitly. `engine.New(ctx, cfg)`. This is the biggest step and it pays off even without an SDK: tests no longer need `SetPrompter`/`ClearAllPlansForTesting`.
	89	+ 2. Module path + public package. Rename `module mm` to an importable path (decision below) and add a thin `mm/` package over `internal/`.
	90	+ 3. Events + typed API. `Session.Send/Stream`, `mm.Ask[T]`, `mm.Tool`, hooks.
	91	+ 4. Front ends on the SDK. REPL, TUI and ACP rebuilt as SDK clients.
	92	+ 5. Examples + docs. Add `examples/` (embed in an HTTP server, CI reviewer bot, agent-as-tool, custom provider), Go `Example*` tests, and Diátaxis EN+FR docs (a "build your first agent in Go" tutorial plus an API reference).
	93	+
	94	+ ### Cheaper complement (language-agnostic "SDK")
	95	+ - A headless mode `mm -p --output-format stream-json` (one JSON event per line, same events as above) lets Python/Node/shell drive mm as a subprocess. The Claude Code and Codex SDKs started this way.
	96	+ - ACP is already a protocol SDK: any ACP client library can drive `mm -acp`.
	97	+
	98	+ Both could ship before step 1. They do not replace the Go SDK, because they cannot do custom tools in-process.
	99	+
	100	+ ### Decisions for you
	101	+ - Module path: `rickub.com/bots-garden/mini-me`? Does the Rickub host serve `go get` (`?go-get=1` meta tag)?
	102	+ - Public package name and location: `mm` at the root (`<module>/mm`) or `sdk/`?
	103	+ - Stability promise: `v0` and experimental until step 4 is done?
	104	+ - Priority: is headless/stream-json wanted first, as a quick win?
15	105	tasks: []
16	106	comments: []

    name: k33g
    email: ph.charriere@gmail.com
  createdAt: 2026-10-02T05:32:33.878Z
--updatedAt: 2026-10-12T09:45:33.355Z
++updatedAt: 2026-10-14T11:21:29.000Z
  labels:
    - priority::urgent
    - kind::feature
  epic: SDK
--body: ""
++body: |
++  ## Proposal: what "Mini Me as an SDK" could look like
++
++  ### Goal
++  Let a Go program embed mm's agent loop (provider registry, built-in tools, skills, MCP, consent, ask_user, sessions, compaction, structured output) without going through the CLI, and have the REPL, the TUI and ACP become three clients of that SDK.
++
++  ### Where we start (checked in the code on 2026-10-14)
++  - **Nothing can be imported today.** The module is `module mm` and every package is under `internal/`.
++  - **The process holds global state**, so you cannot run two agents in one process:
++    - `config.Cfg` (31 references in `main.go`, about 50 more in `internal/`; `engine.New(ctx)` reads it and takes no config)
++    - `ui.SetActive`/`ActiveSink` and `ui.Out`
++    - `consent.SetPrompter`, `elicit.SetPrompter`
++    - `engine.DeclareSkills` / `skills.Declare`
++    - the package-level `planStore` in `tools`
++  - **The seams are already good.** They are what the SDK would expose:
++    - `ui.Sink` (+ `Elicitor`, `UsageSink`, `Speaker`): an event stream of a turn
++    - `engine.Provider`: one implementation per wire protocol, plus a registry
++    - tools are `ai.ToolRef` values built from `*genkit.Genkit` + `*detector.LoopDetector`
++    - `store`/`session` for persistence; `ask.Runner` for agent-to-agent calls
++    - `agent.RunStructuredPrompt` for typed output
++
++  ### Proposed public API (sketch)
++  ```go
++  import "<module>/mm"
++
++  a, err := mm.New(ctx,
++      mm.WithProvider("llamacpp", mm.BaseURL("http://localhost:8080"), mm.Model("qwen3.8-27b")),
++      mm.WithSystem(prompt),                  // or mm.FromYAML("agent.yaml"): same file as the CLI
++      mm.WithTools(mm.Bash(), mm.ReadFile(), mm.EditFile(), mm.AskUser()),
++      mm.WithSkills("./skills"),
++      mm.WithMCP(servers...),
++      mm.WithWorkDir(dir),
++      mm.WithPermissions(mm.AskWith(func(ctx context.Context, c mm.ToolCall) mm.Decision { ... })),
++      mm.WithElicitor(myFormUI),              // ask_user answered by the host app
++  )
++  defer a.Close()
++
++  s := a.NewSession()                         // or a.ResumeSession(id) with a Store
++  reply, err := s.Send(ctx, "fix the failing test")          // blocking
++  for ev, err := range s.Stream(ctx, "explain main.go") {    // iter.Seq2[mm.Event, error]
++      switch e := ev.(type) {
++      case mm.TextDelta:  ...
++      case mm.Reasoning:  ...
++      case mm.ToolStart, mm.ToolEnd: ...
++      case mm.Usage:      ...
++      case mm.Compacted:  ...
++      }
++  }
++
++  // Typed output: generic wrapper around structured output
++  type Verdict struct{ OK bool; Reason string }
++  v, err := mm.Ask[Verdict](ctx, a, "does this diff break the API?")
++
++  // Custom tools: same loop detector, consent gate and events as the built-ins
++  mm.Tool("get_ticket", "Read a ticket by id",
++      func(ctx context.Context, tc mm.ToolContext, in struct{ ID int }) (Ticket, error) { ... })
++
++  // Agents as tools: in-process, instead of today's /ask subprocess
++  reviewer, _ := mm.New(ctx, ...)
++  a2, _ := mm.New(ctx, mm.WithTools(reviewer.AsTool("ask_reviewer", "...")))
++  ```
++  Extension points:
++  - **Hooks**: `OnBeforeTool` (can veto or rewrite), `OnAfterTool`, `OnBeforeModel`, `OnTurnEnd`. Use them for audit, guardrails and tracing (today `trace:`).
++  - **`mm.RegisterProvider(p)`**: for a protocol mm does not speak yet.
++  - **`mm.Store` interface**: the file store (today's `store`) by default, plus an in-memory one for tests and servers.
++
++  ### Design rules I would hold to
++  1. **Do not leak Genkit in the public types.** Ticket 76 (v1.10 → v1.13.1) shows that Genkit changes. The SDK would expose its own types (`Message`, `ToolCall`, `Event`) and convert at the boundary. Genkit would stay an implementation detail.
++  2. **No package-level state after phase 1.** Everything hangs off `*mm.Agent` / `*mm.Session`, so two agents can run in one process (needed for agents as tools and for servers).
++  3. **The SDK never writes to stdout/stdin.** Output goes to events; questions go to `Permissions`/`Elicitor`. The terminal behaviour (tools that print themselves, `consent.Terminal`) becomes the REPL's own sink.
++  4. **The YAML stays the reference.** `mm.FromYAML` and the options build the same `Config`, so a demo agent from `demos/` can be loaded by a program unchanged.
++  5. **Dogfooding is the proof.** `main.go` + `internal/agent` + `internal/tui` + `internal/acp` are rewritten on top of `mm`. If the CLI cannot be built on the SDK, the SDK is not ready.
++
++  ### Plan in mergeable steps (CLI behaviour unchanged at each step)
++  1. **Remove the globals.** Add a `Runtime` (config, sink, prompters, plan store, declared skills) passed down explicitly. `engine.New(ctx, cfg)`. This is the biggest step and it pays off even without an SDK: tests no longer need `SetPrompter`/`ClearAllPlansForTesting`.
++  2. **Module path + public package.** Rename `module mm` to an importable path (decision below) and add a thin `mm/` package over `internal/`.
++  3. **Events + typed API.** `Session.Send/Stream`, `mm.Ask[T]`, `mm.Tool`, hooks.
++  4. **Front ends on the SDK.** REPL, TUI and ACP rebuilt as SDK clients.
++  5. **Examples + docs.** Add `examples/` (embed in an HTTP server, CI reviewer bot, agent-as-tool, custom provider), Go `Example*` tests, and Diátaxis EN+FR docs (a "build your first agent in Go" tutorial plus an API reference).
++
++  ### Cheaper complement (language-agnostic "SDK")
++  - A headless mode `mm -p --output-format stream-json` (one JSON event per line, same events as above) lets Python/Node/shell drive mm as a subprocess. The Claude Code and Codex SDKs started this way.
++  - ACP is already a protocol SDK: any ACP client library can drive `mm -acp`.
++
++  Both could ship before step 1. They do not replace the Go SDK, because they cannot do custom tools in-process.
++
++  ### Decisions for you
++  - **Module path**: `rickub.com/bots-garden/mini-me`? Does the Rickub host serve `go get` (`?go-get=1` meta tag)?
++  - **Public package name and location**: `mm` at the root (`<module>/mm`) or `sdk/`?
++  - **Stability promise**: `v0` and experimental until step 4 is done?
++  - **Priority**: is headless/stream-json wanted first, as a quick win?
  tasks: []
  comments: []

modified demos/agents-md-file/project/greet.sh +0 -0 Viewed

old mode 100755
new mode 100644

old mode 100755
new mode 100644

modified demos/gemini-style/README.en.md +19 -1 Viewed

@@ -8,7 +8,7 @@ A general coding agent for `mm` whose system prompt follows [Gemini CLI](https:/
8	8	\|---\|---\|
9	9	\| Model \| `hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M` (llmman), 18.1 GB \|
10	10	\| Prompt \| Gemini CLI's core prompt (`packages/core/src/prompts/snippets.ts`, interactive variant), same sections, same order \|
11		-\| Tools \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user` \|
	11	+\| Tools \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user`, `lsp` \|
12	12	\| Project rules \| the project's `GEMINI.md`, as in Gemini CLI \|
13	13
14	14	## Prerequisites
@@ -34,6 +34,23 @@ Like Gemini CLI in its default mode, the agent asks before every change (`yo
34	34
35	35	The agent reads the project's `GEMINI.md`; set `agentsMd.path: AGENTS.md` for a project that keeps its instructions there.
36	36
	37	+## Language servers (`lsp`)
	38	+
	39	+The agent has mm's `lsp` tool — definition, references, hover, symbols, diagnostics, rename — for three languages. Install the servers you need; each one is optional:
	40	+
	41	+\| Language \| Server \| Install \|
	42	+\|---\|---\|---\|
	43	+\| Go (`.go`) \| `gopls` \| `go install golang.org/x/tools/gopls@latest` \|
	44	+\| Rust (`.rs`) \| `rust-analyzer` \| `rustup component add rust-analyzer` \|
	45	+\| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) \| `tsc --lsp --stdio` \| `npm i -g typescript` (7 or later) \|
	46	+
	47	+- A server missing from the `PATH` is a warning in the banner and is skipped; with none installed, the tool is not declared and the agent uses `grep`.
	48	+- A server starts on the first `lsp` call for one of its files, in the directory mm runs in (the project root), and stays up for the session.
	49	+- Node: the project needs a `jsconfig.json` or `tsconfig.json`; without one each file is seen alone and `references`/`rename` miss the other files. TypeScript 7 serves the protocol itself; with TypeScript 5, use `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, commented in the config).
	50	+- Rust: rust-analyzer indexes the crate after it starts; the first calls can answer "no reference found" or "content modified". The prompt tells the agent to call again once. Rename from the file that defines the function: in `main.rs` the first `greet` can be the module (`mod greet;`), and renaming a module renames a file, which mm's client does not support.
	51	+
	52	+Measured on 2026-10-12, "rename the function everywhere" on a two-file project per language (`AGENT_YOLO=true mm -p`): Go — through `lsp`, 1/1; Node (TypeScript 7, with a `jsconfig.json`) — through `lsp`, 2/2; Rust — through `lsp` 2/3 (the third run hit the `mod greet;` case above and fell back to `edit_file`, correct result; the "on the file that defines X" rule was added after it, not re-measured). On "where is X defined / called", Gemma 4 searches with `grep`, which answers correctly on a small project: `lsp` needs a file path, which the agent does not have yet.
	53	+
37	54	## What was kept from Gemini CLI's prompt
38	55
39	56	The sections of the interactive variant, in their order: identity and approval mode; Core Mandates (Security & System Integrity, Context Efficiency, Engineering Standards — Directives vs Inquiries, Explain Before Acting, testing); Primary Workflows (Research → Strategy → Execution, each sub-task Plan → Act → Validate, "Validation is the only path to finality", Strategic Re-evaluation after three failed fixes, New Applications with its default stack); Operational Guidelines (Tone and Style, Security and Safety, Tool Usage with the tool-response and post-edit rules); Git Repository. The wording is Gemini CLI's wherever it applies unchanged.
@@ -53,6 +70,7 @@ The sections of the interactive variant, in their order: identity and approval m
53	70	\| `is_background: true`, Tab to focus an interactive shell \| `nohup … &`, "bash has no stdin" \| mm's `bash`. \|
54	71	\| YOLO-mode section on when to use `ask_user` \| the same three criteria, always on \| mm has `ask_user` (same name) in every mode. \|
55	72	\| "Answer in …" (none) \| "answer in the language of the user's message" \| Added, as in the other demos. \|
	73	+\| (no language server) \| `lsp` tool for Go, Rust, JavaScript/TypeScript, with its rules in the tool section \| An mm addition: compiler-exact references and renames instead of `grep` and hand edits. \|
56	74
57	75	No tool-call examples, as in Gemini CLI. Gemma 4 writes its calls in its own format (`<\|tool_call>call:name{key:<\|"\|>value<\|"\|>}<tool_call\|>`), which llama.cpp parses.
58	76

  |---|---|
  | Model | `hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M` (llmman), 18.1 GB |
  | Prompt | Gemini CLI's core prompt (`packages/core/src/prompts/snippets.ts`, interactive variant), same sections, same order |
--| Tools | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user` |
++| Tools | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user`, `lsp` |
  | Project rules | the project's `GEMINI.md`, as in Gemini CLI |
  ## Prerequisites
  The agent reads the project's `GEMINI.md`; set `agentsMd.path: AGENTS.md` for a project that keeps its instructions there.
++## Language servers (`lsp`)
++
++The agent has mm's `lsp` tool — definition, references, hover, symbols, diagnostics, rename — for three languages. Install the servers you need; each one is optional:
++
++| Language | Server | Install |
++|---|---|---|
++| Go (`.go`) | `gopls` | `go install golang.org/x/tools/gopls@latest` |
++| Rust (`.rs`) | `rust-analyzer` | `rustup component add rust-analyzer` |
++| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) | `tsc --lsp --stdio` | `npm i -g typescript` (7 or later) |
++
++- A server missing from the `PATH` is a warning in the banner and is skipped; with none installed, the tool is not declared and the agent uses `grep`.
++- A server starts on the first `lsp` call for one of its files, in the directory mm runs in (the project root), and stays up for the session.
++- **Node:** the project needs a `jsconfig.json` or `tsconfig.json`; without one each file is seen alone and `references`/`rename` miss the other files. TypeScript 7 serves the protocol itself; with TypeScript 5, use `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, commented in the config).
++- **Rust:** rust-analyzer indexes the crate after it starts; the first calls can answer "no reference found" or "content modified". The prompt tells the agent to call again once. Rename from the file that defines the function: in `main.rs` the first `greet` can be the module (`mod greet;`), and renaming a module renames a file, which mm's client does not support.
++
++Measured on 2026-10-12, "rename the function everywhere" on a two-file project per language (`AGENT_YOLO=true mm -p`): Go — through `lsp`, 1/1; Node (TypeScript 7, with a `jsconfig.json`) — through `lsp`, 2/2; Rust — through `lsp` 2/3 (the third run hit the `mod greet;` case above and fell back to `edit_file`, correct result; the "on the file that defines X" rule was added after it, not re-measured). On "where is X defined / called", Gemma 4 searches with `grep`, which answers correctly on a small project: `lsp` needs a file path, which the agent does not have yet.
++
  ## What was kept from Gemini CLI's prompt
  The sections of the interactive variant, in their order: identity and approval mode; Core Mandates (Security & System Integrity, Context Efficiency, Engineering Standards — Directives vs Inquiries, Explain Before Acting, testing); Primary Workflows (Research → Strategy → Execution, each sub-task Plan → Act → Validate, "Validation is the only path to finality", Strategic Re-evaluation after three failed fixes, New Applications with its default stack); Operational Guidelines (Tone and Style, Security and Safety, Tool Usage with the tool-response and post-edit rules); Git Repository. The wording is Gemini CLI's wherever it applies unchanged.
  | `is_background: true`, Tab to focus an interactive shell | `nohup … &`, "bash has no stdin" | mm's `bash`. |
  | YOLO-mode section on when to use `ask_user` | the same three criteria, always on | mm has `ask_user` (same name) in every mode. |
  | "Answer in …" (none) | "answer in the language of the user's message" | Added, as in the other demos. |
++| (no language server) | `lsp` tool for Go, Rust, JavaScript/TypeScript, with its rules in the tool section | An mm addition: compiler-exact references and renames instead of `grep` and hand edits. |
  No tool-call examples, as in Gemini CLI. Gemma 4 writes its calls in its own format (`<|tool_call>call:name{key:<|"|>value<|"|>}<tool_call|>`), which llama.cpp parses.

modified demos/gemini-style/README.fr.md +19 -1 Viewed

@@ -8,7 +8,7 @@ Un agent de code généraliste pour `mm`, dont le prompt système suit celui de
8	8	\|---\|---\|
9	9	\| Modèle \| `hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M` (llmman), 18,1 Go \|
10	10	\| Prompt \| le prompt principal de Gemini CLI (`packages/core/src/prompts/snippets.ts`, variante interactive), mêmes sections, même ordre \|
11		-\| Outils \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user` \|
	11	+\| Outils \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user`, `lsp` \|
12	12	\| Règles du projet \| le `GEMINI.md` du projet, comme dans Gemini CLI \|
13	13
14	14	## Prérequis
@@ -34,6 +34,23 @@ Comme Gemini CLI dans son mode par défaut, l'agent **demande avant chaque modif
34	34
35	35	L'agent lit le `GEMINI.md` du projet ; mettez `agentsMd.path: AGENTS.md` pour un projet qui garde ses instructions là.
36	36
	37	+## Serveurs de langage (`lsp`)
	38	+
	39	+L'agent dispose de l'outil `lsp` de mm — définition, références, survol, symboles, diagnostics, renommage — pour trois langages. Installez les serveurs dont vous avez besoin ; chacun est facultatif :
	40	+
	41	+\| Langage \| Serveur \| Installation \|
	42	+\|---\|---\|---\|
	43	+\| Go (`.go`) \| `gopls` \| `go install golang.org/x/tools/gopls@latest` \|
	44	+\| Rust (`.rs`) \| `rust-analyzer` \| `rustup component add rust-analyzer` \|
	45	+\| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) \| `tsc --lsp --stdio` \| `npm i -g typescript` (version 7 ou plus) \|
	46	+
	47	+- Un serveur absent du `PATH` donne un avertissement dans la bannière et est ignoré ; sans aucun serveur installé, l'outil n'est pas déclaré et l'agent utilise `grep`.
	48	+- Un serveur démarre au premier appel `lsp` sur l'un de ses fichiers, dans le répertoire où mm est lancé (la racine du projet), et reste actif pendant la session.
	49	+- Node : le projet doit avoir un `jsconfig.json` ou un `tsconfig.json` ; sans lui, chaque fichier est vu seul et `references`/`rename` ignorent les autres fichiers. TypeScript 7 sert lui-même le protocole ; avec TypeScript 5, utilisez `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, en commentaire dans la configuration).
	50	+- Rust : rust-analyzer indexe la crate après son démarrage ; les premiers appels peuvent répondre « no reference found » ou « content modified ». Le prompt demande à l'agent de rappeler une fois. Renommez depuis le fichier qui définit la fonction : dans `main.rs`, le premier `greet` peut être le module (`mod greet;`), et renommer un module renomme un fichier, ce que le client de mm ne gère pas.
	51	+
	52	+Mesuré le 2026-10-12, « renomme la fonction partout » sur un projet de deux fichiers par langage (`AGENT_YOLO=true mm -p`) : Go — via `lsp`, 1/1 ; Node (TypeScript 7, avec un `jsconfig.json`) — via `lsp`, 2/2 ; Rust — via `lsp` 2/3 (le troisième essai est tombé sur le cas `mod greet;` ci-dessus et s'est rabattu sur `edit_file`, résultat correct ; la règle « sur le fichier qui définit X » a été ajoutée ensuite, sans nouvelle mesure). Sur « où est défini / appelé X », Gemma 4 cherche avec `grep`, qui répond juste sur un petit projet : `lsp` demande un chemin de fichier, que l'agent n'a pas encore.
	53	+
37	54	## Ce qui est repris du prompt de Gemini CLI
38	55
39	56	Les sections de la variante interactive, dans leur ordre : identité et mode d'approbation ; Core Mandates (Security & System Integrity, Context Efficiency, Engineering Standards — Directives contre Inquiries, Explain Before Acting, tests) ; Primary Workflows (Research → Strategy → Execution, chaque sous-tâche en Plan → Act → Validate, « Validation is the only path to finality », Strategic Re-evaluation après trois corrections ratées, New Applications avec sa pile par défaut) ; Operational Guidelines (Tone and Style, Security and Safety, Tool Usage avec les règles de réponse après un outil et après une modification) ; Git Repository. Les règles gardent la formulation de Gemini CLI partout où elles s'appliquent telles quelles. Le prompt reste en anglais, comme l'original.
@@ -53,6 +70,7 @@ Les sections de la variante interactive, dans leur ordre : identité et mode d'a
53	70	\| `is_background: true`, Tab pour donner le focus à un shell interactif \| `nohup … &`, « bash n'a pas de stdin » \| Le `bash` de mm. \|
54	71	\| Section mode YOLO sur quand utiliser `ask_user` \| les trois mêmes critères, toujours actifs \| mm a `ask_user` (même nom) dans tous les modes. \|
55	72	\| aucune consigne de langue \| « réponds dans la langue du message de l'utilisateur » \| Ajoutée, comme dans les autres démos. \|
	73	+\| (pas de serveur de langage) \| outil `lsp` pour Go, Rust, JavaScript/TypeScript, avec ses règles dans la section des outils \| Un ajout de mm : références et renommages exacts, fournis par le compilateur, plutôt que `grep` et des modifications à la main. \|
56	74
57	75	Pas d'exemples d'appels d'outils, comme dans Gemini CLI. Gemma 4 écrit ses appels dans son propre format (`<\|tool_call>call:nom{clé:<\|"\|>valeur<\|"\|>}<tool_call\|>`), que llama.cpp analyse.
58	76

  |---|---|
  | Modèle | `hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M` (llmman), 18,1 Go |
  | Prompt | le prompt principal de Gemini CLI (`packages/core/src/prompts/snippets.ts`, variante interactive), mêmes sections, même ordre |
--| Outils | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user` |
++| Outils | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `ask_user`, `lsp` |
  | Règles du projet | le `GEMINI.md` du projet, comme dans Gemini CLI |
  ## Prérequis
  L'agent lit le `GEMINI.md` du projet ; mettez `agentsMd.path: AGENTS.md` pour un projet qui garde ses instructions là.
++## Serveurs de langage (`lsp`)
++
++L'agent dispose de l'outil `lsp` de mm — définition, références, survol, symboles, diagnostics, renommage — pour trois langages. Installez les serveurs dont vous avez besoin ; chacun est facultatif :
++
++| Langage | Serveur | Installation |
++|---|---|---|
++| Go (`.go`) | `gopls` | `go install golang.org/x/tools/gopls@latest` |
++| Rust (`.rs`) | `rust-analyzer` | `rustup component add rust-analyzer` |
++| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) | `tsc --lsp --stdio` | `npm i -g typescript` (version 7 ou plus) |
++
++- Un serveur absent du `PATH` donne un avertissement dans la bannière et est ignoré ; sans aucun serveur installé, l'outil n'est pas déclaré et l'agent utilise `grep`.
++- Un serveur démarre au premier appel `lsp` sur l'un de ses fichiers, dans le répertoire où mm est lancé (la racine du projet), et reste actif pendant la session.
++- **Node :** le projet doit avoir un `jsconfig.json` ou un `tsconfig.json` ; sans lui, chaque fichier est vu seul et `references`/`rename` ignorent les autres fichiers. TypeScript 7 sert lui-même le protocole ; avec TypeScript 5, utilisez `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, en commentaire dans la configuration).
++- **Rust :** rust-analyzer indexe la crate après son démarrage ; les premiers appels peuvent répondre « no reference found » ou « content modified ». Le prompt demande à l'agent de rappeler une fois. Renommez depuis le fichier qui définit la fonction : dans `main.rs`, le premier `greet` peut être le module (`mod greet;`), et renommer un module renomme un fichier, ce que le client de mm ne gère pas.
++
++Mesuré le 2026-10-12, « renomme la fonction partout » sur un projet de deux fichiers par langage (`AGENT_YOLO=true mm -p`) : Go — via `lsp`, 1/1 ; Node (TypeScript 7, avec un `jsconfig.json`) — via `lsp`, 2/2 ; Rust — via `lsp` 2/3 (le troisième essai est tombé sur le cas `mod greet;` ci-dessus et s'est rabattu sur `edit_file`, résultat correct ; la règle « sur le fichier qui définit X » a été ajoutée ensuite, sans nouvelle mesure). Sur « où est défini / appelé X », Gemma 4 cherche avec `grep`, qui répond juste sur un petit projet : `lsp` demande un chemin de fichier, que l'agent n'a pas encore.
++
  ## Ce qui est repris du prompt de Gemini CLI
  Les sections de la variante interactive, dans leur ordre : identité et mode d'approbation ; Core Mandates (Security & System Integrity, Context Efficiency, Engineering Standards — Directives contre Inquiries, Explain Before Acting, tests) ; Primary Workflows (Research → Strategy → Execution, chaque sous-tâche en Plan → Act → Validate, « Validation is the only path to finality », Strategic Re-evaluation après trois corrections ratées, New Applications avec sa pile par défaut) ; Operational Guidelines (Tone and Style, Security and Safety, Tool Usage avec les règles de réponse après un outil et après une modification) ; Git Repository. Les règles gardent la formulation de Gemini CLI partout où elles s'appliquent telles quelles. Le prompt reste en anglais, comme l'original.
  | `is_background: true`, Tab pour donner le focus à un shell interactif | `nohup … &`, « bash n'a pas de stdin » | Le `bash` de mm. |
  | Section mode YOLO sur quand utiliser `ask_user` | les trois mêmes critères, toujours actifs | mm a `ask_user` (même nom) dans tous les modes. |
  | aucune consigne de langue | « réponds dans la langue du message de l'utilisateur » | Ajoutée, comme dans les autres démos. |
++| (pas de serveur de langage) | outil `lsp` pour Go, Rust, JavaScript/TypeScript, avec ses règles dans la section des outils | Un ajout de mm : références et renommages exacts, fournis par le compilateur, plutôt que `grep` et des modifications à la main. |
  Pas d'exemples d'appels d'outils, comme dans Gemini CLI. Gemma 4 écrit ses appels dans son propre format (`<|tool_call>call:nom{clé:<|"|>valeur<|"|>}<tool_call|>`), que llama.cpp analyse.

modified demos/gemini-style/agent.yaml +35 -2 Viewed

@@ -19,6 +19,9 @@
19	19	# llmman pull hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M
20	20	# llmman serve
21	21	#
	22	+# Language servers for the `lsp` tool (each optional, see `lsp:` below):
	23	+# gopls, rust-analyzer, tsc (TypeScript 7, for JavaScript and TypeScript).
	24	+#
22	25	# Run it from the project you want to work on:
23	26	#
24	27	# cd ~/src/my-project
@@ -89,6 +92,30 @@ askUserTool: true # ask_user — the same name in Gemini CLI
89	92	fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
90	93	skillsDir: no-skills # the New Applications workflow is in the prompt, as in Gemini CLI
91	94
	95	+# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
	96	+# answered by the project's language server (not in Gemini CLI — an mm addition).
	97	+# Each server starts on the first call for one of its extensions. A server
	98	+# missing from the PATH is a banner warning and is skipped; with none at all,
	99	+# the tool is not declared and the agent falls back to bash + grep.
	100	+lsp:
	101	+ servers:
	102	+ - name: gopls # go install golang.org/x/tools/gopls@latest
	103	+ command: gopls
	104	+ extensions: [".go"]
	105	+ - name: rust-analyzer # rustup component add rust-analyzer
	106	+ command: rust-analyzer
	107	+ extensions: [".rs"]
	108	+ # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
	109	+ # The project needs a jsconfig.json or tsconfig.json, or the server sees
	110	+ # each file alone and finds no cross-file reference.
	111	+ - name: typescript # npm i -g typescript (7 or later)
	112	+ command: tsc
	113	+ args: ["--lsp", "--stdio"]
	114	+ extensions: [".js", ".jsx", ".ts", ".tsx"]
	115	+ # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
	116	+ # command: typescript-language-server
	117	+ # args: ["--stdio"]
	118	+
92	119	# Gemini CLI reads GEMINI.md; so does this agent. Change `path` to AGENTS.md
93	120	# for a project that keeps its instructions there.
94	121	agentsMd:
@@ -129,7 +156,8 @@ system: \|
129	156	## Context Efficiency
130	157	Be strategic in your use of the available tools to minimize unnecessary context usage while still providing the best answer that you can.
131	158	- The full history goes with each message: the larger the context early in the session, the more expensive each later turn is. Unnecessary turns are generally more expensive than other kinds of wasted context.
132		- - Prefer `bash` with `grep -n` (with `-C 3` for context, and `--include` to narrow the scope) to locate points of interest instead of reading many files one by one; a search with enough context often lets you skip reading the file before editing.
	159	+ - For a question about a symbol — where it is defined, who calls or uses it, its type — call `lsp` first: one call answers with the exact positions, where `grep` also matches comments, strings and unrelated names.
	160	+ - Otherwise, prefer `bash` with `grep -n` (with `-C 3` for context, and `--include` to narrow the scope) to locate points of interest instead of reading many files one by one; a search with enough context often lets you skip reading the file before editing.
133	161	- Read small files whole; read large files in ranges with `read_file` (`start`, `end`).
134	162	- `edit_file` fails when an `old` text is ambiguous, which costs a turn: read enough first to make each edit unambiguous.
135	163	- Your primary goal is still to do your best quality work. Efficiency is an important, but secondary concern.
@@ -153,7 +181,7 @@ system: \|
153	181	## Development Lifecycle
154	182	Operate using a Research -> Strategy -> Execution lifecycle. For the Execution phase, resolve each sub-task through an iterative Plan -> Act -> Validate cycle.
155	183
156		- 1. Research: Systematically map the codebase and validate assumptions. Use `bash` searches (`grep -rn`, `git ls-files`, `find`) to understand file structures, existing code patterns, and conventions. Use `read_file` to validate all assumptions. Prioritize empirical reproduction of reported issues to confirm the failure state.
	184	+ 1. Research: Systematically map the codebase and validate assumptions. Use `bash` searches (`grep -rn`, `git ls-files`, `find`) to understand file structures, existing code patterns, and conventions; for a question about a symbol (where it is defined, who uses it, its type), use `lsp` instead. Use `read_file` to validate all assumptions. Prioritize empirical reproduction of reported issues to confirm the failure state.
157	185	2. Strategy: Formulate a grounded plan based on your research. Share a concise summary of your strategy. For complex tasks, break them down into smaller subtasks and track them with the `plan` tool.
158	186	3. Execution: For each sub-task:
159	187	- Plan: Define the specific implementation approach and the testing strategy to verify the change.
@@ -202,6 +230,11 @@ system: \|
202	230	- Post-Edit Response Rules: After an edit (`edit_file`, `write_file`), you MUST ALWAYS either continue with the next tool call or say in text what changed and what you will verify next. Never end a turn with an empty response after an edit.
203	231	- One Call per Reply: Call one tool per reply and read its result before the next one.
204	232	- Paths: Paths are relative to the working directory (the project root).
	233	+ - Language Servers: `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). Prefer it to `grep` for anything about a symbol:
	234	+ - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
	235	+ - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
	236	+ - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
	237	+ `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
205	238	- Background Processes: `bash` waits for the command to end and kills it after a timeout. For a command that does not stop on its own (a server), start it in the background with its output in a file — `nohup go run . > /tmp/app.log 2>&1 &` —, check it, and stop it when done.
206	239	- Interactive Commands: Always prefer non-interactive commands (e.g., 'run once' or 'CI' flags for test runners, 'git --no-pager'); `bash` has no stdin.
207	240	- Asking the User: `ask_user` puts questions to the user (choices, several choices, a text, yes/no) and waits for the answers. Use it only when a wrong decision would cause significant re-work or the request is fundamentally ambiguous with no reasonable default; otherwise make a reasonable decision and follow the project's conventions.

  #   llmman pull hf.co/unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M
  #   llmman serve
  #
++# Language servers for the `lsp` tool (each optional, see `lsp:` below):
++#   gopls, rust-analyzer, tsc (TypeScript 7, for JavaScript and TypeScript).
++#
  # Run it from the project you want to work on:
  #
  #   cd ~/src/my-project
  fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
  skillsDir: no-skills    # the New Applications workflow is in the prompt, as in Gemini CLI
++# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
++# answered by the project's language server (not in Gemini CLI — an mm addition).
++# Each server starts on the first call for one of its extensions. A server
++# missing from the PATH is a banner warning and is skipped; with none at all,
++# the tool is not declared and the agent falls back to bash + grep.
++lsp:
++  servers:
++    - name: gopls                    # go install golang.org/x/tools/gopls@latest
++      command: gopls
++      extensions: [".go"]
++    - name: rust-analyzer            # rustup component add rust-analyzer
++      command: rust-analyzer
++      extensions: [".rs"]
++    # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
++    # The project needs a jsconfig.json or tsconfig.json, or the server sees
++    # each file alone and finds no cross-file reference.
++    - name: typescript               # npm i -g typescript   (7 or later)
++      command: tsc
++      args: ["--lsp", "--stdio"]
++      extensions: [".js", ".jsx", ".ts", ".tsx"]
++    # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
++    #   command: typescript-language-server
++    #   args: ["--stdio"]
++
  # Gemini CLI reads GEMINI.md; so does this agent. Change `path` to AGENTS.md
  # for a project that keeps its instructions there.
  agentsMd:
    ## Context Efficiency
    Be strategic in your use of the available tools to minimize unnecessary context usage while still providing the best answer that you can.
    - The full history goes with each message: the larger the context early in the session, the more expensive each later turn is. Unnecessary turns are generally more expensive than other kinds of wasted context.
--  - Prefer `bash` with `grep -n` (with `-C 3` for context, and `--include` to narrow the scope) to locate points of interest instead of reading many files one by one; a search with enough context often lets you skip reading the file before editing.
++  - For a question about a symbol — where it is defined, who calls or uses it, its type — call `lsp` first: one call answers with the exact positions, where `grep` also matches comments, strings and unrelated names.
++  - Otherwise, prefer `bash` with `grep -n` (with `-C 3` for context, and `--include` to narrow the scope) to locate points of interest instead of reading many files one by one; a search with enough context often lets you skip reading the file before editing.
    - Read small files whole; read large files in ranges with `read_file` (`start`, `end`).
    - `edit_file` fails when an `old` text is ambiguous, which costs a turn: read enough first to make each edit unambiguous.
    - Your primary goal is still to do your best quality work. Efficiency is an important, but secondary concern.
    ## Development Lifecycle
    Operate using a **Research -> Strategy -> Execution** lifecycle. For the Execution phase, resolve each sub-task through an iterative **Plan -> Act -> Validate** cycle.
--  1. **Research:** Systematically map the codebase and validate assumptions. Use `bash` searches (`grep -rn`, `git ls-files`, `find`) to understand file structures, existing code patterns, and conventions. Use `read_file` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
++  1. **Research:** Systematically map the codebase and validate assumptions. Use `bash` searches (`grep -rn`, `git ls-files`, `find`) to understand file structures, existing code patterns, and conventions; for a question about a symbol (where it is defined, who uses it, its type), use `lsp` instead. Use `read_file` to validate all assumptions. **Prioritize empirical reproduction of reported issues to confirm the failure state.**
 . **Strategy:** Formulate a grounded plan based on your research. Share a concise summary of your strategy. For complex tasks, break them down into smaller subtasks and track them with the `plan` tool.
 . **Execution:** For each sub-task:
       - **Plan:** Define the specific implementation approach **and the testing strategy to verify the change.**
    - **Post-Edit Response Rules:** After an edit (`edit_file`, `write_file`), you MUST ALWAYS either continue with the next tool call or say in text what changed and what you will verify next. Never end a turn with an empty response after an edit.
    - **One Call per Reply:** Call one tool per reply and read its result before the next one.
    - **Paths:** Paths are relative to the working directory (the project root).
++  - **Language Servers:** `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). Prefer it to `grep` for anything about a symbol:
++    - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
++    - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
++    - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
++    `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column  <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
    - **Background Processes:** `bash` waits for the command to end and kills it after a timeout. For a command that does not stop on its own (a server), start it in the background with its output in a file — `nohup go run . > /tmp/app.log 2>&1 &` —, check it, and stop it when done.
    - **Interactive Commands:** Always prefer non-interactive commands (e.g., 'run once' or 'CI' flags for test runners, 'git --no-pager'); `bash` has no stdin.
    - **Asking the User:** `ask_user` puts questions to the user (choices, several choices, a text, yes/no) and waits for the answers. Use it only when a wrong decision would cause significant re-work or the request is fundamentally ambiguous with no reasonable default; otherwise make a reasonable decision and follow the project's conventions.

modified demos/little-coder/skills/go-htmx-app/starter/check.sh +0 -0 Viewed

old mode 100755
new mode 100644

old mode 100755
new mode 100644

modified demos/qwen-style/README.en.md +19 -1 Viewed

@@ -14,7 +14,7 @@ A general coding agent for `mm` whose system prompt follows [Qwen Code](https://
14	14	\|---\|---\|
15	15	\| Prompt \| Qwen Code's core prompt (`packages/core/src/core/prompts.ts`), same sections, same order \|
16	16	\| Skills \| `new-app` and `simplify`, adapted from Qwen Code's bundled skills \|
17		-\| Tools \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill` \|
	17	+\| Tools \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill`, `lsp` \|
18	18	\| Project rules \| the project's `AGENTS.md` (Qwen Code reads `QWEN.md`) \|
19	19
20	20	## Prerequisites
@@ -46,6 +46,23 @@ AGENT_YOLO=true mm -config …/agent.qwen3.8.yaml -p "go test fails in this proj
46	46
47	47	In an editor (Zed, JetBrains…): `mm -acp -config /path/to/demos/qwen-style/agent.qwen3.8.yaml`.
48	48
	49	+## Language servers (`lsp`)
	50	+
	51	+The agent has mm's `lsp` tool — definition, references, hover, symbols, diagnostics, rename — for three languages. Install the servers you need; each one is optional:
	52	+
	53	+\| Language \| Server \| Install \|
	54	+\|---\|---\|---\|
	55	+\| Go (`.go`) \| `gopls` \| `go install golang.org/x/tools/gopls@latest` \|
	56	+\| Rust (`.rs`) \| `rust-analyzer` \| `rustup component add rust-analyzer` \|
	57	+\| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) \| `tsc --lsp --stdio` \| `npm i -g typescript` (7 or later) \|
	58	+
	59	+- A server missing from the `PATH` is a warning in the banner and is skipped; with none installed, the tool is not declared and the agent uses `grep`.
	60	+- A server starts on the first `lsp` call for one of its files, in the directory mm runs in (the project root), and stays up for the session.
	61	+- Node: the project needs a `jsconfig.json` or `tsconfig.json`; without one each file is seen alone and `references`/`rename` miss the other files. TypeScript 7 serves the protocol itself; with TypeScript 5, use `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, commented in the config).
	62	+- Rust: rust-analyzer indexes the crate after it starts; the first calls can answer "no reference found" or "content modified". The prompt tells the agent to call again once. Rename from the file that defines the function: in `main.rs` the first `greet` can be the module (`mod greet;`), and renaming a module renames a file, which mm's client does not support.
	63	+
	64	+Measured on 2026-10-12 with `agent.qwen3.8.yaml`, "rename the function everywhere" on a two-file project per language (`AGENT_YOLO=true mm -p`): Go, Rust and Node (TypeScript 7, with a `jsconfig.json`) all renamed through `lsp`, 1 run each; on Rust the first call met the indexing and the agent called again. `agent.qwen3.6.yaml` and `agent.coder-next.yaml` share the same prompt and were not measured.
	65	+
49	66	## What was kept from Qwen Code's prompt
50	67
51	68	All the sections, in their order: identity, Core Mandates, Task Management, Software Engineering Tasks (plan → implement → adapt → verify → report faithfully), New Applications, Communicating With the User, Tone and Style, Security and Safety, Using Your Tools, Executing actions with care, Git Repository, Examples, Final Reminder. The wording of the rules is Qwen Code's wherever it applies unchanged.
@@ -67,6 +84,7 @@ All the sections, in their order: identity, Core Mandates, Task Management, Soft
67	84	\| Git section only in a git repository (checked at start-up) \| always present, "when the working directory is a git repository" \| the prompt is static. \|
68	85	\| "Answer in …" (output-language setting) \| "answer in the language of the user's message" \| no language setting in mm. \|
69	86	\| Examples chosen by model name (`[tool_call: …]` notation for Qwen3.8 and Qwen3.6) \| examples in the models' native XML (`<tool_call><function=…><parameter=…>`) \| see below. \|
	87	+\| (no language server) \| `lsp` tool for Go, Rust, JavaScript/TypeScript, with its rules in the tool section \| An mm addition: compiler-exact references and renames instead of `grep` and hand edits. \|
70	88
71	89	## Tuned for each model
72	90

  |---|---|
  | Prompt | Qwen Code's core prompt (`packages/core/src/core/prompts.ts`), same sections, same order |
  | Skills | `new-app` and `simplify`, adapted from Qwen Code's bundled skills |
--| Tools | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill` |
++| Tools | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill`, `lsp` |
  | Project rules | the project's `AGENTS.md` (Qwen Code reads `QWEN.md`) |
  ## Prerequisites
  In an editor (Zed, JetBrains…): `mm -acp -config /path/to/demos/qwen-style/agent.qwen3.8.yaml`.
++## Language servers (`lsp`)
++
++The agent has mm's `lsp` tool — definition, references, hover, symbols, diagnostics, rename — for three languages. Install the servers you need; each one is optional:
++
++| Language | Server | Install |
++|---|---|---|
++| Go (`.go`) | `gopls` | `go install golang.org/x/tools/gopls@latest` |
++| Rust (`.rs`) | `rust-analyzer` | `rustup component add rust-analyzer` |
++| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) | `tsc --lsp --stdio` | `npm i -g typescript` (7 or later) |
++
++- A server missing from the `PATH` is a warning in the banner and is skipped; with none installed, the tool is not declared and the agent uses `grep`.
++- A server starts on the first `lsp` call for one of its files, in the directory mm runs in (the project root), and stays up for the session.
++- **Node:** the project needs a `jsconfig.json` or `tsconfig.json`; without one each file is seen alone and `references`/`rename` miss the other files. TypeScript 7 serves the protocol itself; with TypeScript 5, use `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, commented in the config).
++- **Rust:** rust-analyzer indexes the crate after it starts; the first calls can answer "no reference found" or "content modified". The prompt tells the agent to call again once. Rename from the file that defines the function: in `main.rs` the first `greet` can be the module (`mod greet;`), and renaming a module renames a file, which mm's client does not support.
++
++Measured on 2026-10-12 with `agent.qwen3.8.yaml`, "rename the function everywhere" on a two-file project per language (`AGENT_YOLO=true mm -p`): Go, Rust and Node (TypeScript 7, with a `jsconfig.json`) all renamed through `lsp`, 1 run each; on Rust the first call met the indexing and the agent called again. `agent.qwen3.6.yaml` and `agent.coder-next.yaml` share the same prompt and were not measured.
++
  ## What was kept from Qwen Code's prompt
  All the sections, in their order: identity, Core Mandates, Task Management, Software Engineering Tasks (plan → implement → adapt → verify → report faithfully), New Applications, Communicating With the User, Tone and Style, Security and Safety, Using Your Tools, Executing actions with care, Git Repository, Examples, Final Reminder. The wording of the rules is Qwen Code's wherever it applies unchanged.
  | Git section only in a git repository (checked at start-up) | always present, "when the working directory is a git repository" | the prompt is static. |
  | "Answer in …" (output-language setting) | "answer in the language of the user's message" | no language setting in mm. |
  | Examples chosen by model name (`[tool_call: …]` notation for Qwen3.8 and Qwen3.6) | examples in the **models' native XML** (`<tool_call><function=…><parameter=…>`) | see below. |
++| (no language server) | `lsp` tool for Go, Rust, JavaScript/TypeScript, with its rules in the tool section | An mm addition: compiler-exact references and renames instead of `grep` and hand edits. |
  ## Tuned for each model

modified demos/qwen-style/README.fr.md +19 -1 Viewed

@@ -14,7 +14,7 @@ Un agent de code généraliste pour `mm`, dont le prompt système suit celui de
14	14	\|---\|---\|
15	15	\| Prompt \| le prompt principal de Qwen Code (`packages/core/src/core/prompts.ts`), mêmes sections, même ordre \|
16	16	\| Skills \| `new-app` et `simplify`, adaptées des skills fournies avec Qwen Code \|
17		-\| Outils \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill` \|
	17	+\| Outils \| `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill`, `lsp` \|
18	18	\| Règles du projet \| le `AGENTS.md` du projet (Qwen Code lit `QWEN.md`) \|
19	19
20	20	## Prérequis
@@ -46,6 +46,23 @@ AGENT_YOLO=true mm -config …/agent.qwen3.8.yaml -p "go test échoue dans ce pr
46	46
47	47	Dans un éditeur (Zed, JetBrains…) : `mm -acp -config /chemin/vers/demos/qwen-style/agent.qwen3.8.yaml`.
48	48
	49	+## Serveurs de langage (`lsp`)
	50	+
	51	+L'agent dispose de l'outil `lsp` de mm — définition, références, survol, symboles, diagnostics, renommage — pour trois langages. Installez les serveurs dont vous avez besoin ; chacun est facultatif :
	52	+
	53	+\| Langage \| Serveur \| Installation \|
	54	+\|---\|---\|---\|
	55	+\| Go (`.go`) \| `gopls` \| `go install golang.org/x/tools/gopls@latest` \|
	56	+\| Rust (`.rs`) \| `rust-analyzer` \| `rustup component add rust-analyzer` \|
	57	+\| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) \| `tsc --lsp --stdio` \| `npm i -g typescript` (version 7 ou plus) \|
	58	+
	59	+- Un serveur absent du `PATH` donne un avertissement dans la bannière et est ignoré ; sans aucun serveur installé, l'outil n'est pas déclaré et l'agent utilise `grep`.
	60	+- Un serveur démarre au premier appel `lsp` sur l'un de ses fichiers, dans le répertoire où mm est lancé (la racine du projet), et reste actif pendant la session.
	61	+- Node : le projet doit avoir un `jsconfig.json` ou un `tsconfig.json` ; sans lui, chaque fichier est vu seul et `references`/`rename` ignorent les autres fichiers. TypeScript 7 sert lui-même le protocole ; avec TypeScript 5, utilisez `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, en commentaire dans la configuration).
	62	+- Rust : rust-analyzer indexe la crate après son démarrage ; les premiers appels peuvent répondre « no reference found » ou « content modified ». Le prompt demande à l'agent de rappeler une fois. Renommez depuis le fichier qui définit la fonction : dans `main.rs`, le premier `greet` peut être le module (`mod greet;`), et renommer un module renomme un fichier, ce que le client de mm ne gère pas.
	63	+
	64	+Mesuré le 2026-10-12 avec `agent.qwen3.8.yaml`, « renomme la fonction partout » sur un projet de deux fichiers par langage (`AGENT_YOLO=true mm -p`) : Go, Rust et Node (TypeScript 7, avec un `jsconfig.json`) renommés via `lsp`, un essai chacun ; sur Rust le premier appel a rencontré l'indexation et l'agent a rappelé. `agent.qwen3.6.yaml` et `agent.coder-next.yaml` ont le même prompt et n'ont pas été mesurés.
	65	+
49	66	## Ce qui est repris du prompt de Qwen Code
50	67
51	68	Toutes les sections, dans leur ordre : identité, Core Mandates, Task Management, Software Engineering Tasks (planifier → implémenter → s'adapter → vérifier → rendre compte fidèlement), New Applications, Communicating With the User, Tone and Style, Security and Safety, Using Your Tools, Executing actions with care, Git Repository, Examples, Final Reminder. Les règles gardent la formulation de Qwen Code partout où elles s'appliquent telles quelles. Le prompt reste en anglais, comme l'original.
@@ -67,6 +84,7 @@ Toutes les sections, dans leur ordre : identité, Core Mandates, Task Management
67	84	\| section Git seulement dans un dépôt git (vérifié au démarrage) \| toujours présente, « quand le répertoire de travail est un dépôt git » \| Le prompt est statique. \|
68	85	\| réglage de langue de sortie \| « réponds dans la langue du message de l'utilisateur » \| mm n'a pas ce réglage. \|
69	86	\| exemples choisis d'après le nom du modèle (notation `[tool_call: …]` pour Qwen3.8 et Qwen3.6) \| exemples dans le XML natif des modèles (`<tool_call><function=…><parameter=…>`) \| Voir ci-dessous. \|
	87	+\| (pas de serveur de langage) \| outil `lsp` pour Go, Rust, JavaScript/TypeScript, avec ses règles dans la section des outils \| Un ajout de mm : références et renommages exacts, fournis par le compilateur, plutôt que `grep` et des modifications à la main. \|
70	88
71	89	## Réglé pour chaque modèle
72	90

  |---|---|
  | Prompt | le prompt principal de Qwen Code (`packages/core/src/core/prompts.ts`), mêmes sections, même ordre |
  | Skills | `new-app` et `simplify`, adaptées des skills fournies avec Qwen Code |
--| Outils | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill` |
++| Outils | `bash`, `read_file`, `write_file`, `edit_file`, `plan`, `read_skill`, `lsp` |
  | Règles du projet | le `AGENTS.md` du projet (Qwen Code lit `QWEN.md`) |
  ## Prérequis
  Dans un éditeur (Zed, JetBrains…) : `mm -acp -config /chemin/vers/demos/qwen-style/agent.qwen3.8.yaml`.
++## Serveurs de langage (`lsp`)
++
++L'agent dispose de l'outil `lsp` de mm — définition, références, survol, symboles, diagnostics, renommage — pour trois langages. Installez les serveurs dont vous avez besoin ; chacun est facultatif :
++
++| Langage | Serveur | Installation |
++|---|---|---|
++| Go (`.go`) | `gopls` | `go install golang.org/x/tools/gopls@latest` |
++| Rust (`.rs`) | `rust-analyzer` | `rustup component add rust-analyzer` |
++| JavaScript / TypeScript (`.js`, `.jsx`, `.ts`, `.tsx`) | `tsc --lsp --stdio` | `npm i -g typescript` (version 7 ou plus) |
++
++- Un serveur absent du `PATH` donne un avertissement dans la bannière et est ignoré ; sans aucun serveur installé, l'outil n'est pas déclaré et l'agent utilise `grep`.
++- Un serveur démarre au premier appel `lsp` sur l'un de ses fichiers, dans le répertoire où mm est lancé (la racine du projet), et reste actif pendant la session.
++- **Node :** le projet doit avoir un `jsconfig.json` ou un `tsconfig.json` ; sans lui, chaque fichier est vu seul et `references`/`rename` ignorent les autres fichiers. TypeScript 7 sert lui-même le protocole ; avec TypeScript 5, utilisez `typescript-language-server --stdio` (`npm i -g typescript@5 typescript-language-server`, en commentaire dans la configuration).
++- **Rust :** rust-analyzer indexe la crate après son démarrage ; les premiers appels peuvent répondre « no reference found » ou « content modified ». Le prompt demande à l'agent de rappeler une fois. Renommez depuis le fichier qui définit la fonction : dans `main.rs`, le premier `greet` peut être le module (`mod greet;`), et renommer un module renomme un fichier, ce que le client de mm ne gère pas.
++
++Mesuré le 2026-10-12 avec `agent.qwen3.8.yaml`, « renomme la fonction partout » sur un projet de deux fichiers par langage (`AGENT_YOLO=true mm -p`) : Go, Rust et Node (TypeScript 7, avec un `jsconfig.json`) renommés via `lsp`, un essai chacun ; sur Rust le premier appel a rencontré l'indexation et l'agent a rappelé. `agent.qwen3.6.yaml` et `agent.coder-next.yaml` ont le même prompt et n'ont pas été mesurés.
++
  ## Ce qui est repris du prompt de Qwen Code
  Toutes les sections, dans leur ordre : identité, Core Mandates, Task Management, Software Engineering Tasks (planifier → implémenter → s'adapter → vérifier → rendre compte fidèlement), New Applications, Communicating With the User, Tone and Style, Security and Safety, Using Your Tools, Executing actions with care, Git Repository, Examples, Final Reminder. Les règles gardent la formulation de Qwen Code partout où elles s'appliquent telles quelles. Le prompt reste en anglais, comme l'original.
  | section Git seulement dans un dépôt git (vérifié au démarrage) | toujours présente, « quand le répertoire de travail est un dépôt git » | Le prompt est statique. |
  | réglage de langue de sortie | « réponds dans la langue du message de l'utilisateur » | mm n'a pas ce réglage. |
  | exemples choisis d'après le nom du modèle (notation `[tool_call: …]` pour Qwen3.8 et Qwen3.6) | exemples dans le **XML natif des modèles** (`<tool_call><function=…><parameter=…>`) | Voir ci-dessous. |
++| (pas de serveur de langage) | outil `lsp` pour Go, Rust, JavaScript/TypeScript, avec ses règles dans la section des outils | Un ajout de mm : références et renommages exacts, fournis par le compilateur, plutôt que `grep` et des modifications à la main. |
  ## Réglé pour chaque modèle

modified demos/qwen-style/agent.coder-next.yaml +30 -0 Viewed

@@ -85,6 +85,30 @@ editTools: true # read_file, write_file, edit (edit_file)
85	85	planTool: true # todo_write → mm's `plan`
86	86	fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
87	87
	88	+# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
	89	+# answered by the project's language server (an mm addition). Each server
	90	+# starts on the first call for one of its extensions. A server missing from
	91	+# the PATH is a banner warning and is skipped; with none at all, the tool is
	92	+# not declared and the agent falls back to bash + grep.
	93	+lsp:
	94	+ servers:
	95	+ - name: gopls # go install golang.org/x/tools/gopls@latest
	96	+ command: gopls
	97	+ extensions: [".go"]
	98	+ - name: rust-analyzer # rustup component add rust-analyzer
	99	+ command: rust-analyzer
	100	+ extensions: [".rs"]
	101	+ # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
	102	+ # The project needs a jsconfig.json or tsconfig.json, or the server sees
	103	+ # each file alone and finds no cross-file reference.
	104	+ - name: typescript # npm i -g typescript (7 or later)
	105	+ command: tsc
	106	+ args: ["--lsp", "--stdio"]
	107	+ extensions: [".js", ".jsx", ".ts", ".tsx"]
	108	+ # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
	109	+ # command: typescript-language-server
	110	+ # args: ["--stdio"]
	111	+
88	112	# Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
89	113	# relative path is resolved from the directory mm is started in: from another
90	114	# project, give the absolute path of this demo's skills/ directory. In an
@@ -185,10 +209,16 @@ system: \|
185	209	- To read files use `read_file` instead of cat, head, tail, or sed
186	210	- To edit files use `edit_file` instead of sed or awk
187	211	- To create files use `write_file` instead of cat with heredoc or echo redirection
	212	+ - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
188	213	- Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
189	214	- Tool Fallback: If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
190	215	- One Call per Reply: Call one tool per reply; use its result to decide the next call.
191	216	- File Paths: Paths are relative to the working directory (the project root). Do not invent absolute paths.
	217	+ - Language Servers: `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
	218	+ - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
	219	+ - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
	220	+ - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
	221	+ `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
192	222	- Background Processes: `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
193	223	- Interactive Commands: `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
194	224	- Skills: `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

  planTool: true          # todo_write → mm's `plan`
  fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
++# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
++# answered by the project's language server (an mm addition). Each server
++# starts on the first call for one of its extensions. A server missing from
++# the PATH is a banner warning and is skipped; with none at all, the tool is
++# not declared and the agent falls back to bash + grep.
++lsp:
++  servers:
++    - name: gopls                    # go install golang.org/x/tools/gopls@latest
++      command: gopls
++      extensions: [".go"]
++    - name: rust-analyzer            # rustup component add rust-analyzer
++      command: rust-analyzer
++      extensions: [".rs"]
++    # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
++    # The project needs a jsconfig.json or tsconfig.json, or the server sees
++    # each file alone and finds no cross-file reference.
++    - name: typescript               # npm i -g typescript   (7 or later)
++      command: tsc
++      args: ["--lsp", "--stdio"]
++      extensions: [".js", ".jsx", ".ts", ".tsx"]
++    # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
++    #   command: typescript-language-server
++    #   args: ["--stdio"]
++
  # Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
  # relative path is resolved from the directory mm is started in: from another
  # project, give the absolute path of this demo's skills/ directory. In an
      - To read files use `read_file` instead of cat, head, tail, or sed
      - To edit files use `edit_file` instead of sed or awk
      - To create files use `write_file` instead of cat with heredoc or echo redirection
++    - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
      - Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
    - **Tool Fallback:** If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
    - **One Call per Reply:** Call one tool per reply; use its result to decide the next call.
    - **File Paths:** Paths are relative to the working directory (the project root). Do not invent absolute paths.
++  - **Language Servers:** `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
++    - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
++    - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
++    - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
++    `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column  <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
    - **Background Processes:** `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
    - **Interactive Commands:** `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
    - **Skills:** `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

modified demos/qwen-style/agent.qwen3.6.yaml +30 -0 Viewed

@@ -89,6 +89,30 @@ editTools: true # read_file, write_file, edit (edit_file)
89	89	planTool: true # todo_write → mm's `plan`
90	90	fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
91	91
	92	+# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
	93	+# answered by the project's language server (an mm addition). Each server
	94	+# starts on the first call for one of its extensions. A server missing from
	95	+# the PATH is a banner warning and is skipped; with none at all, the tool is
	96	+# not declared and the agent falls back to bash + grep.
	97	+lsp:
	98	+ servers:
	99	+ - name: gopls # go install golang.org/x/tools/gopls@latest
	100	+ command: gopls
	101	+ extensions: [".go"]
	102	+ - name: rust-analyzer # rustup component add rust-analyzer
	103	+ command: rust-analyzer
	104	+ extensions: [".rs"]
	105	+ # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
	106	+ # The project needs a jsconfig.json or tsconfig.json, or the server sees
	107	+ # each file alone and finds no cross-file reference.
	108	+ - name: typescript # npm i -g typescript (7 or later)
	109	+ command: tsc
	110	+ args: ["--lsp", "--stdio"]
	111	+ extensions: [".js", ".jsx", ".ts", ".tsx"]
	112	+ # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
	113	+ # command: typescript-language-server
	114	+ # args: ["--stdio"]
	115	+
92	116	# Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
93	117	# relative path is resolved from the directory mm is started in: from another
94	118	# project, give the absolute path of this demo's skills/ directory. In an
@@ -189,10 +213,16 @@ system: \|
189	213	- To read files use `read_file` instead of cat, head, tail, or sed
190	214	- To edit files use `edit_file` instead of sed or awk
191	215	- To create files use `write_file` instead of cat with heredoc or echo redirection
	216	+ - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
192	217	- Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
193	218	- Tool Fallback: If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
194	219	- One Call per Reply: Call one tool per reply; use its result to decide the next call.
195	220	- File Paths: Paths are relative to the working directory (the project root). Do not invent absolute paths.
	221	+ - Language Servers: `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
	222	+ - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
	223	+ - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
	224	+ - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
	225	+ `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
196	226	- Background Processes: `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
197	227	- Interactive Commands: `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
198	228	- Skills: `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

  planTool: true          # todo_write → mm's `plan`
  fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
++# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
++# answered by the project's language server (an mm addition). Each server
++# starts on the first call for one of its extensions. A server missing from
++# the PATH is a banner warning and is skipped; with none at all, the tool is
++# not declared and the agent falls back to bash + grep.
++lsp:
++  servers:
++    - name: gopls                    # go install golang.org/x/tools/gopls@latest
++      command: gopls
++      extensions: [".go"]
++    - name: rust-analyzer            # rustup component add rust-analyzer
++      command: rust-analyzer
++      extensions: [".rs"]
++    # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
++    # The project needs a jsconfig.json or tsconfig.json, or the server sees
++    # each file alone and finds no cross-file reference.
++    - name: typescript               # npm i -g typescript   (7 or later)
++      command: tsc
++      args: ["--lsp", "--stdio"]
++      extensions: [".js", ".jsx", ".ts", ".tsx"]
++    # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
++    #   command: typescript-language-server
++    #   args: ["--stdio"]
++
  # Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
  # relative path is resolved from the directory mm is started in: from another
  # project, give the absolute path of this demo's skills/ directory. In an
      - To read files use `read_file` instead of cat, head, tail, or sed
      - To edit files use `edit_file` instead of sed or awk
      - To create files use `write_file` instead of cat with heredoc or echo redirection
++    - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
      - Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
    - **Tool Fallback:** If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
    - **One Call per Reply:** Call one tool per reply; use its result to decide the next call.
    - **File Paths:** Paths are relative to the working directory (the project root). Do not invent absolute paths.
++  - **Language Servers:** `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
++    - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
++    - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
++    - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
++    `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column  <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
    - **Background Processes:** `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
    - **Interactive Commands:** `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
    - **Skills:** `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

modified demos/qwen-style/agent.qwen3.8.yaml +30 -0 Viewed

@@ -100,6 +100,30 @@ editTools: true # read_file, write_file, edit (edit_file)
100	100	planTool: true # todo_write → mm's `plan`
101	101	fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
102	102
	103	+# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
	104	+# answered by the project's language server (an mm addition). Each server
	105	+# starts on the first call for one of its extensions. A server missing from
	106	+# the PATH is a banner warning and is skipped; with none at all, the tool is
	107	+# not declared and the agent falls back to bash + grep.
	108	+lsp:
	109	+ servers:
	110	+ - name: gopls # go install golang.org/x/tools/gopls@latest
	111	+ command: gopls
	112	+ extensions: [".go"]
	113	+ - name: rust-analyzer # rustup component add rust-analyzer
	114	+ command: rust-analyzer
	115	+ extensions: [".rs"]
	116	+ # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
	117	+ # The project needs a jsconfig.json or tsconfig.json, or the server sees
	118	+ # each file alone and finds no cross-file reference.
	119	+ - name: typescript # npm i -g typescript (7 or later)
	120	+ command: tsc
	121	+ args: ["--lsp", "--stdio"]
	122	+ extensions: [".js", ".jsx", ".ts", ".tsx"]
	123	+ # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
	124	+ # command: typescript-language-server
	125	+ # args: ["--stdio"]
	126	+
103	127	# Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
104	128	# relative path is resolved from the directory mm is started in: from another
105	129	# project, give the absolute path of this demo's skills/ directory. In an
@@ -199,10 +223,16 @@ system: \|
199	223	- To read files use `read_file` instead of cat, head, tail, or sed
200	224	- To edit files use `edit_file` instead of sed or awk
201	225	- To create files use `write_file` instead of cat with heredoc or echo redirection
	226	+ - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
202	227	- Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
203	228	- Tool Fallback: If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
204	229	- One Call per Reply: Call one tool per reply; use its result to decide the next call.
205	230	- File Paths: Paths are relative to the working directory (the project root). Do not invent absolute paths.
	231	+ - Language Servers: `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
	232	+ - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
	233	+ - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
	234	+ - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
	235	+ `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
206	236	- Background Processes: `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
207	237	- Interactive Commands: `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
208	238	- Skills: `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

  planTool: true          # todo_write → mm's `plan`
  fetchContentTool: false # web_fetch → mm's `fetch_content`: off, it reaches the network
++# The `lsp` tool: definition, references, hover, symbols, diagnostics, rename,
++# answered by the project's language server (an mm addition). Each server
++# starts on the first call for one of its extensions. A server missing from
++# the PATH is a banner warning and is skipped; with none at all, the tool is
++# not declared and the agent falls back to bash + grep.
++lsp:
++  servers:
++    - name: gopls                    # go install golang.org/x/tools/gopls@latest
++      command: gopls
++      extensions: [".go"]
++    - name: rust-analyzer            # rustup component add rust-analyzer
++      command: rust-analyzer
++      extensions: [".rs"]
++    # Node: TypeScript 7 serves JavaScript and TypeScript itself (`tsc --lsp`).
++    # The project needs a jsconfig.json or tsconfig.json, or the server sees
++    # each file alone and finds no cross-file reference.
++    - name: typescript               # npm i -g typescript   (7 or later)
++      command: tsc
++      args: ["--lsp", "--stdio"]
++      extensions: [".js", ".jsx", ".ts", ".tsx"]
++    # With TypeScript 5 instead: npm i -g typescript@5 typescript-language-server
++    #   command: typescript-language-server
++    #   args: ["--stdio"]
++
  # Qwen Code's bundled skills new-app and simplify, adapted. In the terminal a
  # relative path is resolved from the directory mm is started in: from another
  # project, give the absolute path of this demo's skills/ directory. In an
      - To read files use `read_file` instead of cat, head, tail, or sed
      - To edit files use `edit_file` instead of sed or awk
      - To create files use `write_file` instead of cat with heredoc or echo redirection
++    - To find where a symbol is defined, used or renamed, use `lsp` instead of grep
      - Reserve `bash` for system commands and terminal operations: builds, tests, git, and searching (`rg` or `grep -rn` for content, `git ls-files`, `find` or `ls` for files).
    - **Tool Fallback:** If a tool returns empty, unhelpful, or unexpected results, try an alternative tool that can accomplish the same goal before telling the user it cannot be done. Never give up after a single tool failure.
    - **One Call per Reply:** Call one tool per reply; use its result to decide the next call.
    - **File Paths:** Paths are relative to the working directory (the project root). Do not invent absolute paths.
++  - **Language Servers:** `lsp` asks the project's language server what the compiler knows; its description lists the file extensions it covers (Go, Rust, JavaScript/TypeScript when their servers are installed). For a question about a symbol, prefer it to `grep`:
++    - where X is defined → `definition`; who calls or uses X → `references`; the type or signature of X → `hover`;
++    - what a file contains → `symbols`; errors in a file → `diagnostics` (path only);
++    - rename X to Y everywhere → `rename` with `new_name` Y, on the file that DEFINES X. Never rename a symbol with `edit_file`.
++    `path` is the FILE that contains the symbol, never a directory (find it with `grep -rln` first). Point at the symbol with its name in `symbol`, spelled exactly as in the code; add `line` only to pick one occurrence among several. Before changing a symbol used in several files, call `references` and say how many places are affected. After editing a file it covers, call `diagnostics` on it and fix what it reports before running the tests. Its answers (`path:line:column  <source line>`) are evidence: quote them. "no language server for" means use `bash`; "not found in" means the name is misspelled — read the file and copy it; "no reference found" or "content modified" right after the first call means the server is still indexing — call again once.
    - **Background Processes:** `bash` waits for the command to end and kills it after a timeout. For commands that do not stop on their own (a server), start them in the background with their output in a file — `nohup go run . > /tmp/app.log 2>&1 &` — check them (`sleep 2; curl -s localhost:8080`), and stop them when you are done (`kill %1` does not work across calls: use `pkill -f '<pattern>'` or the PID you saved).
    - **Interactive Commands:** `bash` has no stdin. Avoid commands that wait for input (e.g. `git rebase -i`); use non-interactive versions (e.g. `npm init -y` instead of `npm init`), and otherwise tell the user to run the command themselves.
    - **Skills:** `read_skill` loads a procedure listed in its description. Load it before starting the work it covers, then follow it.

modified demos/team/starter/check.sh +0 -0 Viewed

old mode 100755
new mode 100644

old mode 100755
new mode 100644

modified skills/create-agent/model_facts.py +0 -0 Viewed

old mode 100755
new mode 100644

old mode 100755
new mode 100644

modified tests/tool-order/proxy.py +0 -0 Viewed

old mode 100644
new mode 100755

old mode 100644
new mode 100755

modified tests/tool-order/session.py +0 -0 Viewed

old mode 100644
new mode 100755

old mode 100644
new mode 100755

🛟 Updated.