command-code 1.9.1 → 1.11.0

package/CHANGELOG.md

@@ -1,17 +1,28 @@
 # command-code
 
-## 1.9.1
+## 1.11.0
 
-### Patch Changes
+### Minor Changes
+
+- feat: syntax highlighting for code blocks and markdown in the TUI (#3319g)
+- feat(mods): render `cmd.ui.setStatus` segments in the TUI footer
+- feat: use Shades of Purple syntax theme (#3328)
+- fix: size model picker name column to widest label #3329
 
-- fix(tui): /copy the whole reply, not just its last block (#3313)
+## 1.10.0
 
-## Unreleased
+### Minor Changes
+
+- feat(mods): render `cmd.ui.setStatus` segments in the TUI footer
+- feat(tui): make /feedback tell you what enter will do, and add /issue (#3316)
+
+## 1.9.1
 
 ### Patch Changes
 
+- fix(tui): /copy to copy the whole reply, not just its last block
 - fix: Restore colorized Edit/Write diff view in the TUI
-- fix: Render the Edit diff for legacy `oldValue`/`newValue` tool calls and keep long Write previews honest when expanded
+- fix: Render the Edit diff for legacy `oldValue`/`newValue` tool calls
 
 ## 1.9.0
 

package/dist/bundled/command-code-knowledge/reference/custom-slash-commands.md

@@ -122,7 +122,7 @@ Every built-in command, grouped by area. Aliases are shown in parentheses on the
 | `/changelog [all]` | See what's new in Command Code (`all` for the full history)    |
 | `/courses`         | Open Command Code courses in your browser                      |
 | `/update`          | Update Command Code to the latest version                      |
-| `/feedback`        | Share feedback or report bugs                                  |
+| `/feedback [title]` (alias `/issue`) | Report a bug or share feedback — opens a prefilled GitHub issue |
 | `/trace`           | Copy the current trace id; required for support debugging      |
 | `/copy`            | Copy the last response to the clipboard                        |
 
@@ -251,7 +251,7 @@ When multiple sources define the same name, dispatch resolves in this order - fi
 3. **Custom** commands (`.commandcode/commands/`, `~/.commandcode/commands/`)
 4. **Skills**
 
-So a custom command can never override a built-in, and a skill shadowed by any of the above resolves to its owner. Shadowed skills still render in the menu with a `- shadowed by /<name>` note so you know they exist. Lookup is case-insensitive (`/Reload` resolves to `/reload`).
+So a custom command can never override a built-in, and a skill shadowed by any of the above resolves to its owner. Shadowed skills still render in the menu with a `- shadowed by /<name>` note so you know they exist, and they run under the `skill:` namespace: `/skill:<name>` bypasses this whole ladder and only ever resolves to a skill. Lookup is case-insensitive (`/Reload` resolves to `/reload`).
 
 ### Skill invocation
 

package/dist/bundled/command-code-knowledge/reference/models.md

@@ -9,7 +9,7 @@ The model catalog — every id `/model`, `--model`, `model:effort` shorthand, an
 | Id (use EXACTLY this) | Name | Context | Efforts | $/1M in/out | Best for |
 |---|---|---|---|---|---|
 | `deepseek/deepseek-v4-pro` | DeepSeek V4 Pro | 1M | high, max | $0.435/$0.87 | hybrid-attention long-context reasoning |
-| `deepseek/deepseek-v4-flash` | DeepSeek V4 Flash | 1M | high, max | $0.14/$0.28 | fast hybrid-attention reasoning |
+| `deepseek/deepseek-v4-flash` | DeepSeek V4 Flash (latest) | 1M | high, max | $0.14/$0.28 | fast hybrid-attention reasoning |
 | `moonshotai/Kimi-K3` | Kimi K3 | 1M | — | $3/$15 | long-horizon coding & knowledge work with 1M context |
 | `moonshotai/Kimi-K2.7-Code` | Kimi K2.7 Code | 256K | — | $0.95/$4 | improved long-horizon coding with vision |
 | `moonshotai/Kimi-K2.7-Code-Highspeed` | Kimi K2.7 Code HighSpeed | 262K | — | $1.9/$8 | high-speed long-horizon coding with vision |

package/dist/bundled/command-code-knowledge/reference/product-help.md

@@ -46,7 +46,7 @@
 - /login: Log in to Command Code
 - /logout: Log out of Command Code
 - /courses: Open Command Code courses in your browser
-- /feedback [title]: Share feedback or report bugs (optional title)
+- /feedback [title]: Report a bug or share feedback — opens a prefilled GitHub issue (alias: /issue)
 - /trace: Copy the current trace id; required for support debugging
 - /session-file: Show the current session id and path to the on-disk session file
 - /copy: Copy the last response to the clipboard
@@ -80,7 +80,7 @@
 - cmd help: Display help information
 - cmd whoami: Show current user
 - cmd update: Update Command Code to the latest version
-- cmd feedback [title]: Share feedback or report bugs (optional title)
+- cmd feedback [title]: Report a bug or share feedback — opens a GitHub issue (alias: cmd issue)
 - cmd taste: Manage taste learning packages
 - cmd taste learn <source>: Learn taste from a local repository or GitHub repo
 - cmd learn-taste: Learn command structure from repositories

package/dist/bundled/command-code-knowledge/reference/skills.md

@@ -213,7 +213,8 @@ When two locations provide the same skill name, the higher-precedence copy wins
 **What happens on a collision.** When a skill name matches a built-in or a custom command:
 
 - Typing `/<name>` always resolves to the higher-precedence owner - the skill is not invoked.
-- The skill still appears in the `/` menu with a `[skill]` badge and a ` - shadowed by /<owner>` note, so you can see it exists and understand why `/<name>` runs the built-in command instead. Command Code prefers visibility with a marker over silently dropping the row.
+- Run the skill as `/skill:<name>` instead. The `skill:` namespace skips the precedence ladder entirely and can only ever resolve to a skill, so it works for every skill, shadowed or not. Typing `/skill:` on its own lists all of them.
+- The skill still appears in the `/` menu with a `[skill]` badge and a ` - shadowed by /<owner>, runs as /skill:<name>` note, and selecting that row inserts the namespaced form. Command Code prefers visibility with a marker over silently dropping the row.
 
 ---
 
@@ -238,7 +239,7 @@ This opens an interactive menu showing:
 
 Every installed skill is also surfaced as a first-class slash command in the `/` menu. If you install a skill named `pr-desc`, you will see `/pr-desc`, sorted after built-ins and any custom commands in the slash menu.
 
-If a skill name collides with a built-in or a custom command, the skill still appears in the `/` menu with a `[skill]` badge and a ` - shadowed by /<owner>` note. Typing `/<name>` always resolves to the higher-precedence owner, not the skill. See [Selection priority](#selection-priority) above for the full order.
+If a skill name collides with a built-in or a custom command, the skill still appears in the `/` menu with a `[skill]` badge and a ` - shadowed by /<owner>` note. Typing `/<name>` always resolves to the higher-precedence owner, not the skill - use `/skill:<name>` to run the skill itself. See [Selection priority](#selection-priority) above for the full order.
 
 ---
 
@@ -255,6 +256,19 @@ Type `/skill-name` at the start of your prompt to run that skill for the current
 /pr-desc update the description based on new changes
 ```
 
+Every skill also answers to the namespaced form `/skill:<name>`, which never
+resolves to anything but a skill:
+
+```bash
+# In Command Code session
+/skill:changelog          # the changelog skill, not the built-in /changelog
+/skill changelog          # same thing, space instead of colon
+/skill:                   # browse every skill in the menu
+```
+
+Reach for it when a skill's name is taken by a built-in or custom command - see
+[What happens on a collision](#selection-priority).
+
 ### 2. Inline slash reference
 
 Drop `/skill-name` anywhere inside a longer prompt to pin that skill without losing your natural phrasing. You can mix multiple skills in a single prompt:
@@ -790,7 +804,7 @@ cmd skills add https://github.com/remotion-dev/skills --skill remotion-best-prac
 
 **Name collisions.** Skill names share the `/` menu with built-in commands (`/clear`, `/help`, `/share`, `/rewind`, …) and with the custom commands in `.commandcode/commands/`. Built-ins and custom commands take precedence - typing `/<name>` resolves to the owner, not to the skill.
 
-If you install a skill whose name collides with one of those, `cmd skills add` still completes normally - nothing blocks the install. The skill then appears in the `/` menu with a `[skill]` badge and a `shadowed by /<owner>` note so you can see it exists, while `/<name>` continues to route to the higher-precedence owner. See [Selection priority](#selection-priority) for the full order.
+If you install a skill whose name collides with one of those, `cmd skills add` still completes normally - nothing blocks the install. The skill then appears in the `/` menu with a `[skill]` badge and a `shadowed by /<owner>` note, and runs as `/skill:<name>`, while a plain `/<name>` continues to route to the higher-precedence owner. See [Selection priority](#selection-priority) for the full order.
 
 ### cmd skills list
 

package/dist/bundled/mod-builder/reference/api.md

@@ -12,7 +12,7 @@
 | `cmd.cwd` | `string` | workspace root |
 | `cmd.session` | `ModSessionApi \| undefined` | persistence seam; undefined until bound |
 | `cmd.events` | `ModEventBus` | `emit(channel, data?)` / `on(channel, handler)` cross-mod bus |
-| `cmd.ui` | `ModUi` | `notify` / `confirm` / `select` / `input` / `setStatus` / `widget` / `refreshWidgets` |
+| `cmd.ui` | `ModUi` | `notify` / `confirm` / `select` / `input` / `setStatus` / `widget` / `refreshWidgets` / `capabilities` |
 | `cmd.sessions` | `ModSessionControls` | `compact` / `tree` / `leafId` / `navigateTree` / `setLabel` |
 
 ## Registration (factory-time; each returns `Disposable`)

package/dist/bundled/mod-builder/reference/overview.md

@@ -222,7 +222,7 @@ Ask for any of these by name or by what you want:
 
 - **Hooks mutate, `on` observes.** Event handlers cannot block tools or rewrite context; that is what `cmd.hooks` is for.
 - **Project mods are trust-gated** like project skills: they load only after the workspace trust prompt, because a mod is arbitrary code. User-scope and `--mod` mods always load. There is no sandbox - install packages you trust. Package installs run npm with `--ignore-scripts` (mods are jiti-loaded TypeScript; they need no build step, so lifecycle scripts are pure attack surface).
-- **Print mode loads user-scope and `--mod` mods only**, with the ui bridge degraded to headless defaults (confirm → false, select/input → undefined - never auto-approved; `setStatus`/`widget` render nowhere). Project mods stay out of headless runs because print never shows a trust prompt; pass `--dangerously-skip-permissions` to opt a repo's own mods into a headless run (CI).
+- **Print mode loads user-scope and `--mod` mods only**, with the ui bridge degraded to headless defaults (confirm → false, select/input → undefined - never auto-approved; `setStatus`/`widget` render nowhere, and `cmd.ui.capabilities.status` is false). Project mods stay out of headless runs because print never shows a trust prompt; pass `--dangerously-skip-permissions` to opt a repo's own mods into a headless run (CI).
 - **Mod-queued messages don't echo in the feed** the way typed input does - they land in the transcript and steer the model, but the visible record is the model's response.
 - **Rendering is line-based, not component-based.** `cmd.addRenderer` returns styled text lines the host prints as feed rows; mods do not mount React components into the TUI. That keeps renderers host-agnostic (the same mod renders in any future host) and a crashing renderer degrades to a warning notice, never a broken screen.
 - **Reload is the `/reload` path.** Mods load once per process; `/reload` restarts the process, which re-discovers and re-imports every mod (jiti caches nothing between loads). There is no in-place hot swap.

package/dist/bundled/mod-builder/reference/packaging.md

@@ -4,19 +4,36 @@
 
 A mod starts life as a loose file in `~/.commandcode/mods/`. When it should be shared - with a team, or the world - it becomes a **package**: an npm package, a git repo, or a local directory that `cmd mods add` installs and Command Code loads on every session.
 
-## Install, remove, list, update
+## Install, remove, list, update, open
 
 ```bash
-cmd mods add npm:@team/review-mod@1.2.0     # npm registry
+cmd mods add cmd-mod-hi                     # bare name = npm package
+cmd mods add @team/review-mod@1.2.0         # scoped npm name, pinned (npm: prefix optional)
 cmd mods add owner/repo@v1                  # GitHub shorthand (any git host via git:<host>/…)
 cmd mods add ./tools/local-mod              # local path, referenced in place
 cmd mods add -g owner/repo                  # user scope instead of project
-cmd mods list
-cmd mods update                             # reinstall missing, reconcile pinned refs
-cmd mods remove owner/repo
+cmd mods list                               # alias: cmd mods ls
+cmd mods update                             # reinstall missing, reconcile pinned refs (alias: up)
+cmd mods remove owner/repo                  # alias: cmd mods rm
+cmd mods remove fun-stuff                   # by the name `mods list` prints
+cmd mods open                               # open the mods dir (project); --user for ~
 ```
 
-Sources persist in the `mods.sources` settings key (project scope writes `.commandcode/settings.json`, `-g` writes `~/.commandcode/settings.json`). Identity is version/ref-agnostic - `owner/repo@v1` and `https://github.com/owner/repo` are the same package, and a project entry shadows the same identity at user scope. Installs land in `<scope>/.commandcode/mods/.registry/{npm,git}/…`; startup never runs npm/git on its own - a configured-but-missing package is a warning pointing at `cmd mods update`.
+`cmd mods list` prints one line per mod - name, scope, origin - project mods first, then user, then package-provided:
+
+```
+Mods (2)
+  guard · project · .commandcode/mods/guard.ts
+  cmd-mod-hi · user · from npm:cmd-mod-hi
+```
+
+The origin is the file for a drop-in mod and `from <source>` for a package mod (whose file lives under `.registry/`, which you never edit by hand). Built-in mods are Command Code's own internals and are never listed. Configured package sources stay out of the output entirely unless one needs attention - not installed, or installed but contributing no mods.
+
+`remove` (`rm`) takes **either** a source or the mod NAME `cmd mods list` prints, and removes whatever backs that name: a drop-in file or directory is deleted from the mods dir, a package-provided mod removes its source (and says which sibling mods went with it), a `mods.paths` mod drops its settings entry. Scope follows where the mod actually lives, so a user-scope mod does not need `-g`; a source that is configured in neither scope reports that instead of a silent success.
+
+`cmd mods open` opens the drop-in mods directory - `<project>/.commandcode/mods` by default, `~/.commandcode/mods` with `--user` (`-g`) - creating it if it does not exist yet. `--path` prints the directory instead of opening it.
+
+A source with no slash is an npm package name, and so is a `@scope/name` - git shorthand always carries an `owner/repo` slash, so `npm:` is optional (an explicit `git:` prefix always wins). Sources persist in the `mods.sources` settings key (project scope writes `.commandcode/settings.json`, `-g` writes `~/.commandcode/settings.json`). Identity is version/ref-agnostic - `owner/repo@v1` and `https://github.com/owner/repo` are the same package, and a project entry shadows the same identity at user scope. Installs land in `<scope>/.commandcode/mods/.registry/{npm,git}/…`; startup never runs npm/git on its own - a configured-but-missing package is a warning pointing at `cmd mods update`.
 
 ## What a package ships
 

package/dist/bundled/mod-builder/reference/ui.md

@@ -11,9 +11,23 @@ Everything a mod can put on screen rides `cmd.ui`, `cmd.addRenderer`, and `cmd.s
 
 ## Footer status segments and editor widgets
 
-> **Not wired into the TUI yet.** `cmd.ui.setStatus`, `cmd.ui.widget`, and `cmd.ui.refreshWidgets` exist on the surface and are safe to call - they never throw and return the documented `Disposable` - but they currently render **nowhere** (no-op everywhere, interactive and headless alike). The contract below is the intended design; wire-up is pending. Build against it, but don't rely on anything appearing on screen today.
+> **Widgets are not wired into the TUI yet.** `cmd.ui.widget` and `cmd.ui.refreshWidgets` exist on the surface and are safe to call - they never throw and return the documented `Disposable` - but they currently render **nowhere**. The contract below is the intended design; wire-up is pending. `cmd.ui.setStatus` **is** wired and renders today.
 
-`cmd.ui.setStatus(text | null)` - a persistent per-mod segment in the TUI footer (under the input panel). One segment per mod: a new call replaces the text, `null` clears it, the returned `Disposable` clears it too. Segments from multiple mods concatenate in load order. Headless: renders nowhere (no-op).
+`cmd.ui.setStatus(text | null)` - a persistent per-mod segment in the TUI footer (under the input panel). One segment per mod: a new call replaces the text, `null` (or whitespace-only text) clears it, and the returned `Disposable` clears it too - but only while it still owns the segment, so a stale handle disposing late can't wipe a newer status. Segments from multiple mods render on one row in load order, and a call from async code repaints on its own. Text is printed verbatim (style it with ansi), collapsed to a single line: newlines and tabs become spaces. Headless: stored, rendered nowhere.
+
+```ts
+cmd.hooks({
+	onSessionStart: () => cmd.ui.setStatus('#channel ✓ connected'),
+	onSessionEnd: () => cmd.ui.setStatus(null),
+});
+```
+
+`cmd.ui.capabilities.status` - whether this host renders footer segments (true in the interactive TUI, false headless). Use it to pick a surface instead of shipping a permanent fallback:
+
+```ts
+if (cmd.ui.capabilities.status) cmd.ui.setStatus(text);
+else cmd.ui.notify(text);
+```
 
 `cmd.ui.widget({placement: 'above-editor' | 'below-editor', render: () => lines})` - a line-based widget the TUI renders around the input panel. Same verbatim-lines contract as `addRenderer` (style with ansi); `render` re-runs on every repaint, and `cmd.ui.refreshWidgets()` requests a repaint after your data changes. A throwing render is skipped (reported as a `mod_error`) so siblings keep rendering. Headless: no-op.
 
@@ -43,6 +57,6 @@ Rendering is deliberately **line-based, not component-based**: mods return style
 | `notify` | notice feed row | printed notice |
 | `confirm` | modal | resolves `false` |
 | `select` / `input` | modal | resolves `undefined` |
-| `setStatus` | no-op (wire-up pending) | no-op |
+| `setStatus` | footer segment under the input | stored, rendered nowhere |
 | `widget` | no-op (wire-up pending) | no-op |
 | `showEntry` | rendered feed row | dropped |

package/dist/bundled/mod-builder/reference/verify.md

@@ -26,7 +26,8 @@ Your mod must appear, with no load warnings. If it does not appear, the warning
 - **Tool** - ask the model to use it by name ("call count_todos"). The tool call renders in the feed like any built-in.
 - **Hook** - trigger the behavior it guards (for a `beforeToolCall` blocker, ask for the blocked action and watch the block reason land as the tool result).
 - **Input interception** - type the pattern `transformInput` matches and confirm the rewrite/consume happened.
-- **Status / widget** - `cmd.ui.setStatus` / `cmd.ui.widget` / `cmd.ui.refreshWidgets` must return without throwing and hand back a `Disposable`. They render **nothing** today (TUI wire-up pending - see the [UI surface](./ui.md#ui-surface) note), so don't expect a footer segment or editor widget to appear yet; only verify the calls are safe.
+- **Status** - `cmd.ui.setStatus('text')` must show up as a segment on the row under the input, replace itself on the next call, and disappear on `setStatus(null)`.
+- **Widget** - `cmd.ui.widget` / `cmd.ui.refreshWidgets` must return without throwing and hand back a `Disposable`. They render **nothing** today (TUI wire-up pending - see the [UI surface](./ui.md#ui-surface) note), so don't expect an editor widget to appear yet; only verify the calls are safe.
 - **Renderer** - `cmd.showEntry` rows render styled; an unregistered type pretty-prints as JSON.
 
 ### Test: block-dangerous-commands guards rm -rf