Mulmoterminal Help

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

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 and source files.