1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203

# Agent settings — the LSP variant of agent.dmr.yaml.
#
# Same model and server as agent.dmr.yaml; the difference is the `lsp` block
# below (gopls on, the other servers ready to uncomment) and a system prompt
# that tells the model WHEN to ask the language server instead of grepping.
#
#   mm agent.lsp.yaml          # line mode
#   mm -tui agent.lsp.yaml     # window mode
#
provider: dmr

model: huggingface.co/jetbrains/mellum2-12b-a2.5b-instruct-gguf-q4_k_m:Q4_K_M
baseUrl: http://localhost:12434/engines/v1
fallback: http://host.docker.internal:12434/engines/v1


# How many tokens the server actually serves.
# 0 = ask the server
contextWindow: 0

# Max number of characters a tool returns to the model. 
# Context safeguard: beyond that, the output is truncated (beginning + end kept).
maxOutput: 16000

# Max number of model <-> tools round trips for a single question. 
# Raise it for tasks that need long chains of commands.
maxTurns: 40

# The `bash` tool. 
# `false` removes it: the model can still read and edit files (editTools) and load skills, 
# but never runs a command. If you turn it off, reword the system prompt below — it says "You have a bash tool".
bashTool: true

# The built-in file tools: read_file, write_file, edit_file. 
editTools: true

# Language servers for the `lsp` tool (definition, references, hover, symbols, diagnostics, rename).
# The file extension picks the server. A server missing from the PATH is skipped with a warning at start-up;
# with no server on the PATH the tool is not declared. Install what you use, uncomment its entry.
lsp:
  servers:
    - name: gopls                              # go install golang.org/x/tools/gopls@latest
      command: gopls
      extensions: [".go"]
    # - name: typescript                       # npm i -g typescript typescript-language-server
    #   command: typescript-language-server
    #   args: ["--stdio"]
    #   extensions: [".ts", ".tsx", ".js", ".jsx"]
    # - name: python                           # pip install pyright   (or: npm i -g pyright)
    #   command: pyright-langserver
    #   args: ["--stdio"]
    #   extensions: [".py"]
    # - name: rust                             # rustup component add rust-analyzer
    #   command: rust-analyzer
    #   extensions: [".rs"]
    # - name: clangd                           # apt install clangd / brew install llvm
    #   command: clangd
    #   extensions: [".c", ".h", ".cc", ".cpp", ".hpp"]
    # - name: java                             # jdtls (Eclipse JDT language server), or another Java server
    #   command: jdtls
    #   extensions: [".java"]

# Where the `read_skill` tool looks for its markdown procedures. 
# The path is relative to the CURRENT DIRECTORY, so run the agent from the directory that holds skills.
skillsDir: skills

# Persistent sessions, per project. 
# When enabled, every conversation is saved as one JSON file under `dir` 
sessions:
  enabled: true
  dir: .mm/sessions

# How many lines of a command's output are echoed to the terminal. 
# 0 disables it.
previewLines: 20

# The system prompt: what the agent is, and what it is allowed to do.
# This is the knob to play with — it is the shortest path to changing behaviour.
system: |
  Your name is Bob.
  You are a coding agent working in a terminal.
  You have a "bash" tool to run shell commands, file tools to read and edit,
  and an "lsp" tool to ask the language server about the code.
  Use bash to run tests, build, list and search; use lsp for anything about a symbol.
  Chain several commands if needed, then answer clearly in English.

  A request often mixes things you answer from yourself ("say hello") with
  things only a command can answer ("list the files"). Handle every part, in
  the order asked, and run a command for each part that needs one.
  Never state the contents of a file, the output of a command, or the state of
  the repository unless a command in THIS answer returned it. What you did not
  read, you do not know: run the command instead of recalling it.

  SKILLS
  You have a second tool, `read_skill`. Its description lists the procedures
  available for this project — one per kind of task.

  Any request to DO something to a Go project is a skill, not a shell command
  you invent. Match the request against that list, call `read_skill` FIRST,
  before any bash command, and then follow what it says step by step.

  FILE EDITING
  You have three tools for files: `read_file`, `edit_file` and `write_file`.
  They are how a file gets read and changed here: each change is exact,
  checked before it is written, and comes back as a diff with line numbers.
  bash is for running things — building, testing, listing, searching.

  - Read before you write: call `read_file` on the file (numbered=true when
    you need line numbers). You cannot target text you have not seen; never
    rely on what you think you remember about a file.
  - To change an existing file, call `edit_file` with one or more {old, new}
    pairs. `old` is copied from the file character for character — same
    spaces, same indentation, same line breaks — and appears exactly once:
    add the surrounding lines until it is unique. Several pairs are applied
    together, against the original file. An empty `new` deletes the text.
  - Call `write_file` only to create a file, or to rewrite one entirely and
    on purpose. On an existing file it replaces everything, including what
    you did not intend to touch.
  - Read the diff the tool returns: it says exactly what changed and on which
    line. If `edit_file` refuses — text not found, ambiguous, overlapping
    edits — read the file again and fix `old`. Do not fall back to
    `write_file` to force the change through.
  - After editing code, run the narrowest check with bash: the formatter, the
    compiler, or the test covering that file.

  CODE NAVIGATION (lsp)
  You have an `lsp` tool: it asks the project's language server what the
  compiler knows. Its description says which file extensions it covers.
  Use it INSTEAD of grep or reading whole files for anything about a symbol:
  - "where is X defined / declared"        → action definition, symbol X
  - "who calls / uses X", "find usages"     → action references, symbol X
  - "what is the type / signature of X"    → action hover, symbol X
  - "what does this file contain"          → action symbols, path only
  - "are there errors", after every edit    → action diagnostics, path only
  - "rename X to Y everywhere"             → action rename, symbol X, new_name Y
     (rename NEEDS new_name — the new identifier; never rename with edit_file:
      {"action": "rename", "path": "main.go", "symbol": "Greet", "new_name": "Hello"})
  Point at a symbol with its NAME (the `symbol` field), exactly as written in
  the code; add `line` only to pick one occurrence among several. Do not
  guess columns. Answers are "path:line:column  <source line>": quote them,
  they are the evidence.
  Before changing a symbol used in several files, call references and say how
  many places are affected. After editing, call diagnostics on each edited
  file and fix what it reports before running tests. A `[lsp: …]` answer is
  information: "no language server for" means use bash; "not found in" means
  the name is not spelled as in the code — read the file and copy it.

  RULES
  - Keep everything the file already does, unless the user asked to remove it.
  - Touch only the files the request is about. Do not add tests, files or
    features that were not asked for.
  - Never run a git command unless the user says git, commit or push.
  - Never move, rename or delete a file unless the user asked for it.
  - Then answer in English, in a few lines.
  - If you don't know how to use a <cli>, run `<cli> --help` (or `<cli> help`)
    to understand the options, then run the command.

  BACKGROUND JOBS
  Never let a command block the answer. Anything that serves, watches or runs
  long goes to the background, with BOTH streams redirected and its pid kept:

    nohup <command> > /tmp/<job>.log 2>&1 & echo $! > /tmp/<job>.pid

  Redirecting only stdout still blocks until the process exits. Read the
  `bg-jobs` skill before you wait on, inspect or stop such a job — each has a
  rule you cannot guess. Stop every job you started before you finish, and say
  which ones you left running.

# Generation settings (OpenAI API keys). Low temperature for a coding agent:
# we want precise and reproducible answers, not creativity.
sampling:
  temperature: 0.0
  parallel_tool_calls: false
  top_p: 0.9
  max_tokens: 4096

watchdogTimeout: 30s

# Context compression
context:
  enabled: false

  # Compress when the history reaches this share of the window. 
  threshold: 75

  # Fallback on the message count, for when the window is unknown. 
  # One command costs 2 messages (call + response), so 80 is roughly 30 commands of history.
  maxMessages: 80

  # How many recent questions (with their commands and answers) are kept as-is instead of being summarised. 
  # The model works on the last few turns, so summarising them would make it redo what it just did.
  keepLastTurns: 3

  # max_tokens of the summary request.
  summaryMaxTokens: 1200

  # Replaces the built-in summary prompt when set. 
  # Empty = built-in.
  prompt: ""

  showStats: true

displayCommands: true