Announcing the Slatewave CLI: One Command to Install Every Theme in the Family

If you’ve installed any of the Slatewave themes by hand, you know the drill: clone the repo or curl the file, drop it in the right config directory (which you have to look up per tool), edit a config line to activate it, restart the app. Multiply by 31 themes. Multiply again across machines.

I just shipped the Slatewave CLI to fix that. One command per theme. One command for all of them. One command to back out cleanly when you change your mind.

The before and after

This is what installing the bat theme looked like before:

mkdir -p "$(bat --config-dir)/themes" \
  && curl -fsSL https://raw.githubusercontent.com/kevinlangleyjr/bat-slatewave/main/Slatewave.tmTheme \
       -o "$(bat --config-dir)/themes/Slatewave.tmTheme" \
  && bat cache --build \
  && echo 'export BAT_THEME=Slatewave' >> ~/.zshrc

Four steps: directory creation, file fetch, cache rebuild, shell export. Every theme has a different shape of that incantation. Some are git clone, some are editor-CLI installs (code --install-extension ...), some are GUI imports where you click around in a Preferences pane.

Now it’s:

slatewave install bat

Same shape for every theme in the family. The CLI knows where each one’s config goes, what activate step it needs, and which tool it depends on being installed first.

What you can do with it

slatewave init                            # interactive setup wizard
slatewave browse                          # TUI catalog with filter, install, uninstall
slatewave list                            # every theme, with install markers
slatewave list --category=editor          # only one category
 
slatewave install <theme>                 # install + activate one theme
slatewave install --all                   # bulk install with a live dashboard
slatewave install --category=editor       # bulk install scoped to a category
slatewave install <theme> --dry-run       # preview the plan
 
slatewave update <theme>                  # re-fetch / git pull
slatewave update --all                    # bulk update with a live dashboard
 
slatewave uninstall <theme>               # reverse files, restore backups
slatewave uninstall --all                 # uninstall everything
 
slatewave status [theme]                  # show install footprint + paths
slatewave info <theme>                    # show manifest details before installing
slatewave doctor                          # diagnose drift across installed themes
slatewave doctor --fix                    # interactively remediate

If you’re new to Slatewave on this machine, run slatewave init. It detects which Slatewave-supported tools are present (parallel sh probes, typically under a second), filters out what it can’t see, and shows you a multi-select of what’s left grouped by category. Pick what you want, hit enter, and the same install pipeline runs through a live dashboard so you can watch it.

If you already have a few themes installed and want to spelunk the catalog, run slatewave browse. Arrow keys to navigate, / to filter, i and u to install or uninstall the focused row.

The manifest model

The interesting part architecturally is that the CLI doesn’t know anything about specific themes. Every Slatewave theme repo ships a slatewave.toml describing how to install it:

[theme]
slug = "btop"
name = "Slatewave for btop"
category = "terminal"
detect_command = "btop --version"
 
[install]
type = "curl"
url  = "https://raw.githubusercontent.com/kevinlangleyjr/btop-slatewave/main/slatewave.theme"
dest = "$HOME/.config/btop/themes/slatewave.theme"
 
[activate]
type  = "ini-key"
file  = "$HOME/.config/btop/btop.conf"
key   = "color_theme"
value = "slatewave"

The CLI dispatches on [install].type and [activate].type. Install types include curl, clone, vscode-ext, marketplace, gui-import, and manual. Activate types include ini-key, gitconfig-include, shell-rc, toml-import, yaml-set, and none.

That’s the whole vocabulary. Adding a new theme to the family doesn’t require a CLI release. You write a new slatewave.toml in the theme’s repo, the CLI’s manifest loader picks it up on the next build, and the same dispatch handles it. The CLI binary and the theme catalog evolve independently.

Manifests can also opt in to specific operating systems with supported_os = ["darwin", "linux", "windows"], with per-OS overrides for paths and commands (detect_command_windows, clone_dest_windows, etc.). That’s how slatewave list on Windows hides themes for tools that don’t have Windows builds: the CLI filters its surface area to what your platform can actually run.

Reversibility, end to end

Theme installers usually treat uninstall as an afterthought. You get good at adding things to your config and bad at removing them, which is how you end up with a ~/.zshrc full of dead exports.

The Slatewave CLI records every install action in ~/.config/slatewave/installed.toml so slatewave uninstall can reverse it cleanly:

• Files the CLI created are deleted.
• Config files the CLI edited (e.g. btop.conf) are restored from a .bak written before the edit.
• Lines appended to shell rc are removed by exact match, plus the # slatewave marker comment.
• Gitconfig includes are unset by path with git config --global --unset-all.
• VSCode-family extensions (VSCode, Cursor, VSCodium, Antigravity) are removed via the matching editor’s CLI.

Every install action backs up the file it’s about to touch. Every activate is idempotent, so re-running slatewave install bat after a clean install changes nothing. --dry-run walks the same plan without writing, so you can preview an install or uninstall before committing.

If something drifts (you edited a config by hand, or a theme repo moved a file), slatewave doctor is read-only and shows you what’s stale, missing, or orphaned. slatewave doctor --fix walks you through it interactively.

Install

macOS / Linux via Homebrew:

brew tap kevinlangleyjr/slatewave
brew install slatewave

Linux distros have native packages on each release (.deb, .rpm, .apk, .pkg.tar.zst). Grab the matching file from the Releases page. These are unsigned, repo-less artifacts, so you fetch them manually.

Windows users download the latest slatewave_windows_*.zip from the same Releases page and put slatewave.exe somewhere on %PATH%. The Windows-supported set is intentionally small right now: VSCode, Cursor, VSCodium, Antigravity, Starship, Oh My Posh, and Windows Terminal. Adding more is a manifest-level change, not a CLI release.

Shell completions are available for zsh, bash, and fish via slatewave completion <shell>. Once installed, slatewave install <TAB> lists every theme, slatewave uninstall <TAB> lists only what’s currently installed, and --category=<TAB> lists just the categories that have themes.

Try it

If you already have a Slatewave theme or two installed by hand, slatewave doctor will tell you whether the CLI can adopt them. If you’re starting fresh, slatewave init is the fastest way in.

brew install kevinlangleyjr/slatewave/slatewave
slatewave init

The whole point of Slatewave is that the workspace feels like one thing. The CLI is the part that makes setting it up feel like one thing too. If you try it and something breaks (or works in an unexpected way), open an issue on the CLI repo or ping me. Especially curious to hear from anyone running it on a Windows-only setup, since that’s where the manifest filtering gets the most of a workout.