/mulmoterminal-help

name: mulmoterminal-help
description: Help desk for questions about MulmoTerminal itself — what it can do, how a feature or a part of the screen works, how to set something up, what is new in this version or in the latest one. Answers from the shipped guide, changelog, source and the running server, never from memory, and names where each fact was checked. Use when the user asks anything about MulmoTerminal that is not "it is broken" (that is mulmoterminal-bug-report) and not "change this setting for me" (that is mulmoterminal-config). Works in whatever language the user writes in.

MulmoTerminal — ask anything about it

**Every answer is read, not remembered.** The guide, the changelog, the source and the running server are on this machine; a sentence that none of them backs is a guess, and a guess about a button that does not exist costs the user longer than "I could not find that". This skill exists so the person asking gets the behaviour of the version they are running, in their own language, with the place it was checked.

Rules that hold in every answer

• **Never answer from memory.** Read the file or call the route, then answer. A general knowledge of

terminals, Claude Code or similar apps is not evidence about MulmoTerminal.

• **Name where you checked** — a guide page, a source file, a route — in one short line after the

answer. The user can follow it, and it is how a wrong answer gets caught.

• **Say which version you are describing.** The running version comes from the server (below). A

newer release may exist; its features are not on this machine and must be introduced as "after you update", never as something the user can click now.

• **The source wins over the guide.** When a page and the implementation disagree, say the page is

behind and answer from the code. When two pages disagree, the newer dated page wins.

• **"Not found" is an answer.** If nothing shipped describes it, say so and offer to look at the

source or to ask in the project's Discussions. Do not fill the gap with what would be plausible.

• **Change nothing.** This skill reads. A user who wants a setting changed is handed to the skill that

owns it (last section); a user whose app misbehaves is handed to `mulmoterminal-bug-report`.

• **Reply in the user's language.** Japanese readers get the `ja` guide; every other language reads

`en` (that is also what the app does). Quote UI words as the user's interface shows them.

• **Short answers, one question at a time.** Lead with the answer, then how to get there, then the

pointer. Offer the published page when the topic is wide.

Step 0 — Find out what is running (once per session)

curl --noproxy localhost -s "http://localhost:${MULMOTERMINAL_PORT:-34567}/api/help/sources"

`MULMOTERMINAL_PORT` is set in every terminal MulmoTerminal opens; the fallback is the default port. The answer names:

• `version` — the running release; `install` — `npm` (installed package) or `git` (a checkout, whose

code may be newer than `version`; its unreleased work is listed under `## Unreleased` in the changelog).

• `packageDir` and, inside it, `files.readme`, `files.changelog`, `files.facts`, `files.guideDir`,

`files.skillsDir`, `files.serverDir`, `files.commonDir`, `files.srcDir`. The `src` directory ships only in a git checkout; `dist/` is the built UI and is not readable prose.

• `urls.guide` (the published guide), `urls.changelog`, `urls.repository`, `urls.issues`.

Then, for the release state:

curl --noproxy localhost -s "http://localhost:${MULMOTERMINAL_PORT:-34567}/api/update-status"

`latest` is non-null only when a newer release exists; `notice` is the one-line update message the app shows, command included; `commit` identifies a git build.

Keep `packageDir`, `version` and the guide language for the rest of the conversation.

Where to look, by kind of question

`GUIDE` below is `files.guideDir/<lang>`. Pages are Jekyll markdown with front matter; the `description:` line of each is its one-line index, so to find the page for a topic:

grep -H "^description:" "$GUIDE"/*.md

| The user asks | Read | | --- | --- | | What can it do? Is there a feature for X? | `feature-list.md` — every capability, one line, with the release it arrived in as `(vX.Y.Z)`; `features.md` — the reference tables by area; `README.md` at `files.readme` | | How do I use X? What is this part of the screen? | The page for the area (table below), then `features.md`. Screenshots are on the published site, not in the package: link `urls.guide` + `<lang>/<page>.html` | | How do I set up X? Which key? What does it accept? | `config.md`, `header-reference.md`; the owning skill's `SKILL.md` under `files.skillsDir` (it documents the keys it writes); then the schema in `files.serverDir/config/`. The sanitized live config: `GET /api/config` | | What is new? What changed? | The next section | | Which agents run, and what each supports | `agents.md`, `providers.md`, `claude-ollama.md`, `accounts.md`, `token-rotation.md` | | Words it uses (cell, roster, cockpit, worktree, chip…) | `glossary.md` | | How it compares; does my history carry over; cost | `faq.md`, `alternatives.md` | | I just installed it | `getting-started.md`, `basics.md`, `scenarios.md` |

Area pages, all under `GUIDE`: `basics.md` (grid, cells, the zoomed views), `header.md` and `header-reference.md` (a cell's buttons and chips), `worktree.md` (git worktrees), `github.md` (PRs and issues), `notifications.md` (sounds, push), `phone.md`, `conversation.md` (cells talking to each other), `from-collection.md` and `shared-apps.md` (collections and the apps built from them), `blueprints.md`, `mulmocast.md`, `remote.md`, `config.md` (the config files and the global keys).

The other bundled skills are documentation too: `files.skillsDir/mulmoterminal-config/SKILL.md` lists the global settings and which skill owns each; `mulmoterminal-bug-report/faq.md` is an index of symptoms to config keys a