mulmoterminal-dirs

Solid

Colour-code and order the directories you actually work in, from wherever you are. Writes each project's `<project>/.mulmoterminal.json` — name badge, project icon image, the seven chrome colours, xterm palette (`theme` / `colors`), terminal font size, `orderPriority` (where it sits in the grid and in the launcher's chips), and `worktreeEnv` (a value of its own per git worktree for each declared variable — a dev-server port, a database name — so two `yarn dev` do not fight over 3000). Starts from your recent MulmoTerminal directories rather than just the current one, reads the configs you already have, works out the convention you have been following, and continues it for the ones that are unset or off-pattern — so a newly cloned repo gets the colour and rank it should have had. Also owns what the header shows once a STATUS takes the background over — `headerStatusColors` (a colour per working / done / blocked) and `headerStatusTint` — in a project's file and as the global default in `~/.mulmoterminal/config.

Data & Documents 211 stars 30 forks Updated today MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
77
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Colour and order the directories you work in MulmoTerminal reads `<project>/.mulmoterminal.json` to style every terminal opened in that directory. There is **no UI that writes this file** — this skill is the way it gets written. Two files ship next to this one: - `palettes.json` — colour presets grouped by vibe, for a user with nothing configured yet. - `dir-config.schema.json` — the generated JSON Schema. "Schema" below matches it. ## The shape of this conversation The unit of work is **the set of directories the user actually opens**, not the current one. Someone who colour-codes projects is doing it so the grid is readable at a glance, and that only works if the colours are decided against each other. So: gather → infer → propose the whole set → apply → look → adjust. Ask with `AskUserQuestion`, one decision at a time, always with concrete options. A beginner should never have to invent a hex code. ### 1. Gather — the directories, and what they already say Read `~/.mulmoterminal/config.json` and take `cwdPresets` (`[{ label, path }]`, most-recent first — the same list the New-terminal launcher offers). That is the population. Worktrees are not recorded into it, so it is the user's real projects rather than every task branch they have ever opened; an older entry that still names one is theirs to keep or remove, not this skill's to prune. Then, for **each** of those paths: ```sh curl -sG "http://localhost:${MULMOTERMINAL_PORT:-34567}/api/dir-config-detail" --dat...

Details

Author
receptron
Repository
receptron/mulmoterminal
Created
2 months ago
Last Updated
today
Language
TypeScript
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

mulmoterminal-theme

Build a colour scheme of your own for MulmoTerminal — one that joins Midnight, Nord, Daylight and Solarized in Settings' theme picker and can then be pinned per project. Writes `themes` in `~/.mulmoterminal/config.json`, the whole-app palette (panels, borders, accent, text), which has no UI for creating one — Settings only lets you pick from what exists. Use when the user wants their own theme, a dark/light variant that isn't shipped, a scheme drawn from a painting, a photo or a brand's colours, or says the built-in themes are too dark, too blue, too low-contrast. For colouring ONE project's cell (its badge and header), or assigning an existing theme to a directory, use mulmoterminal-dirs instead.

211 Updated today
receptron
AI & Automation Solid

mulmoterminal-config

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 load read-out (showLoadAverage), pinned c

211 Updated today
receptron
Code & Development Solid

mulmoterminal-header

Put your own action buttons and info chips in a MulmoTerminal session header — either everywhere (`buttons` / `chips` in `~/.mulmoterminal/config.json`, which has no Settings UI) or for one project (`<project>/.mulmoterminal.json`). Buttons run a shell command in a new cell, type text into the running agent (`/compact`), or open a URL, the file explorer, a diff/PR/wiki overlay, or a new terminal. Chips show live context — branch, context left, diff counts, the PR or issue being worked on. Use when the user wants to add, remove, reorder or hide header buttons or chips, wants a one-click build/test/deploy on a session, wants the header to show something it doesn't, or asks why a button is missing or does nothing. For colours and grid order use mulmoterminal-dirs; for keyboard shortcuts use mulmoterminal-keys.

211 Updated today
receptron