# Agent settings.
#
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

# 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.
  Use it to explore files, run tests, inspect the repository, etc.
  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.

  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