/mulmoterminal-config

name: mulmoterminal-config
description: The way into configuring MulmoTerminal, and the way to find out how it is configured now. Use for a broad or unsure request — "configure MulmoTerminal", "set this up", "customize this", "what can I change?", first-run setup — and route to the skill that owns the area. Also answers "how is this set up right now?", "why isn't my setting working?", "did that take effect?" by reading the live config — the global `~/.mulmoterminal/config.json`, each project's `.mulmoterminal.json`, and what the app ACTUALLY parsed from them — including keys it dropped in validation, which is the difference between a setting you never made and one that silently never applied. Owns the global settings that have no skill of their own — work comments on an issue (issueWorkComments), the PR clone footer (prWorkdirFooter), the closing summary (appendSystemPrompt), the decision digest (decisionDigest), the periodic dev-work log (worklogEnabled), roster row length (cockpitLines), the grid header's usage gauge and how often it measures Claude (usageGauge, usageProbeIntervalMinutes), the grid header's load read-out (showLoadAverage), a search box in the middle of the top bar (paletteSearchBox), an experimental switch for a server on another machine (remoteServer), the occasional terminal theatre (playfulEffects), confetti and when it falls (confetti), pinned collections on the toolbar (toolbarPins), Python a remote bot may run on this machine (botJobs, and the bot tokens for it), a self-hosted GitLab (gitlabHosts), a project's Skill menu (skills), a project's Mulmo menu (decks), and the files a project shows on the phone (mobileFiles). When the request names another area, go straight to that skill instead — mulmoterminal-dirs (colours, grid order, project names, font size), mulmoterminal-theme (your own colour scheme), mulmoterminal-header (buttons and chips), mulmoterminal-keys (shortcuts, copy-on-select, Enter behaviour), mulmoterminal-model (other models and backends, and your own command for starting Claude Code), mulmoterminal-notify (sounds and push).

Configuring MulmoTerminal — start here

This skill does two things: it **routes** to whichever skill owns what the user wants, and it **reports** on how things are configured right now. Anything that writes a setting lives in a sibling skill.

Where settings live

| Place | What | Written by | |---|---|---| | Settings modal | Theme, terminal font size / family / scroll, roster rows, the grid header's load read-out, notification sounds, Push, PR repos, self-hosted GitLab, work comments, PR footer, closing summary, decision digest, dev-work log, copy-on-select, Enter behaviour, launch commands, phone quick commands, MCP servers | the user, in the UI | | `~/.mulmoterminal/config.json` | Everything global — including the five Settings can only SHOW, never edit: `keymap`, `themes`, `providers`, `customAgents`, `buttons` / `chips` | these skills, or by hand | | `<project>/.mulmoterminal.json` | Per-project appearance and behaviour. **No UI writes this file** | these skills only |

**Check Settings first when a request is one setting.** Most global settings now have a control there, so "turn on work comments" is a click rather than a skill run — say where it is and let them choose. The five above are the exception: a keymap binding, a colour scheme, a backend, your own Claude Code command, a header button. Settings SHOWS each of them — what is configured now, and for a backend whether it can be reached — but cannot edit them: they are structured enough to need the questions a skill asks. Every one of those sections carries a button that launches the owning skill.

Routing

Ask what they want to change — one `AskUserQuestion`, concrete options — then invoke that skill and carry on there. Do not re-explain its contents here; the sibling skill is the source of truth.

Two of those areas own a GLOBAL key as well as a per-project one, and the skill owns both halves: `mulmoterminal-dirs` for `headerStatusColors` / `headerStatusTint` (the header while a session is running), `mulmoterminal-notify` for the sounds. Route rather than editing the global file here.

| They want | Skill | |---|---| | Colours for a project, colour-coding several, grid/launcher order, a name badge, a project icon image, terminal font size or font | `mulmoterminal-dirs` | | The header being unreadable, or changing colour, while a session runs | `mulmoterminal-dirs` | | Their **own** colour scheme, appearing in Settings' picker | `mulmoterminal-theme` | | Header buttons or info chips, globally or per project | `mulmoterminal-header` | | Keyboard shortcuts, copy-on-select, Enter vs. newline | `mulmoterminal-keys` | | Another model or backend (OpenRouter, a gateway, a per-project model) | `mulmoterminal-model` | | Their **own command** for starting Claude Code (`ollama launch claude …`, a wrapper script), offered in the Agent Picker | `mulmoterminal-model` | | Which agent a **new cell** opens on, or starting at all **without Claude Code** installed (`defaultAgent`, `--agent`) | `mulmoterminal-model` | | Which moments beep or push, and what they play | `mulmoterminal-notify` | | Work comments on an issue, the PR clone footer, the closing summary, the decision digest, the dev-work log, roster row length, a self-hosted GitLab | **stay here** — [the settings that live here](#the-settings-that-live-here) | | Something is broken and they don't know which setting | **Audit first** (below), then route |

If the request already names an area, skip the question. "Make this project blue" goes straight to `mulmoterminal-dirs`.

**"I want to add my own agent" is two different requests**, and the answer differs by which one: an entry in the **Agent Picker** that runs Claude Code through the user's command line and receives Claude Code's arguments (`customAgents` → `mulmoterminal-model`), or a **launcher chip** that runs a command verbatim with nothing added and no se