/mulmoterminal-dirs

name: mulmoterminal-dirs
description: 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.json`. Use when the user wants to colour-code, theme, rename, reorder, or resize projects in MulmoTerminal — "give this project a colour", "colour-code my repos", "keep my main repos at the top", "the new clone has no colour", "make them consistent", "terminal text is too small", "two worktrees fight over port 3000", "give each worktree its own port / database" — or when the header is hard to read or changes colour while a session is running — "I can't read the header while it's working", "the colour changes when it runs", "keep my header colour while running". For inventing a NEW reusable colour scheme that shows up in Settings, use mulmoterminal-theme instead.

Colour and order the directories you work in

MulmoTerminal reads `<project>/.mulmoterminal.json` to style every terminal opened in that directory. **Settings → Directory settings → Change here** edits one directory's name, seven chrome colours, `headerStatusTint`, `headerStatusColors`, `theme`, `colors`, `fontSize`, `fontFamily`, `orderPriority`, `icon`, `backgroundImage` and `worktreeEnv` key by key, and moves a key between `.mulmoterminal.json` and `.mulmoterminal.local.json`. Everything else, and deciding a convention ACROSS directories, is this skill's job — point a user who only wants to change one of those keys in one place at that form.

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:

curl --noproxy localhost -sG "http://localhost:${MULMOTERMINAL_PORT:-34567}/api/dir-config-detail" --data-urlencode "cwd=$path"

Let `curl` encode `cwd` (`-G` + `--data-urlencode`) rather than interpolating the path into the query: a raw path truncates at the first `#` or `?` and mangles spaces.

Use this route, not your own read of the file. It returns what the app **actually parsed**: the values in force, the keys the file set, and how each fared — applied, dropped in validation, or not a key we read. A hand-read tells you what the file says; only this tells you what is *in effect*, and the difference is the entire content of "I set it and nothing happened". It also resolves the path the way the app does (a preset whose project has since been deleted answers as missing rather than silently reporting on some other directory).

If the server is not running, fall back to reading each `.mulmoterminal.json` directly and say that you could not check what was dropped.

If there are no `cwdPresets` yet, this is a fresh install: configure the current directory from a preset in `palettes.json` and stop.

2. Infer — work out the convention already in use

**Do not skip to a preset when the user already has configs.** They have a scheme; your job is to find it and extend it, not to replace it. Convert every configured colour to HSL and look for:

• **One hue per directory?** In a hand-made scheme, a directory's seven colours are usually one hue

at different saturations and lightnesses. Check whether the hues within a directory agree.

• **Fixed saturation/lightness per role.** `badgeColor` dark and saturated, `headerColor` a little

lighter, `cellColor` near-white, `cellBorderColor` and `dotColor` mid, `buttonColor` pale — the numbers repeat across directories even when the hue does not. Take the median of each role.

• **Hue bands by repository family.** `foo`, `foo2`, `foo3` are clones of one repo and usually sit

in one band, stepping by a constant number of degrees per clone, often getting lighter as the number goes up. That step is what tells you what `foo6` should be.

• **`orderPriority` spacing and blocks.** Ranks are typically multiples of 10, grouped so one repo's

clones are contiguous. You need the step and the free numbers.

**Show the user the rule you found before you use it**, as a small table — hue per family, the S/L per role, the rank blocks. This is the