Back to catalog
Skill Resource

amethyst-theme

Apply the Amethyst Night palette to user-requested apps like VS Code, Kitty, CAVA, btop, and OpenCode, or adapt it to other tools by inspecting their theme format.

Markdown/amethyst-theme.md

This skill applies a shared Amethyst Night theme across apps and tools.

Use it when the user asks to theme a specific app, terminal tool, editor, or config with the existing Amethyst palette, or when they want several tools to match the same look.

Core Goal

Preserve one coherent palette and adapt it to the target app's native theme format instead of inventing a new color system each time.

Always preserve the user's existing config structure where possible. Make the smallest safe change that activates the theme.

Canonical Palette

Use these exact semantic colors unless the user explicitly asks for a variant:

  • `accent`: `#A78BFA`
  • `accentSoft`: `#D3C4FF`
  • `added`: `#8CE0B6`
  • `background`: `#15131C`
  • `border`: `#473B58`
  • `comment`: `#84769A`
  • `editor`: `#1C1826`
  • `entity`: `#C49BFF`
  • `entityName`: `#C89CFF`
  • `error`: `#FF8F9F`
  • `gutter`: `#9789AD`
  • `info`: `#AA9ACF`
  • `keybind`: `#FAFAFA`
  • `keyword`: `#E0B8FF`
  • `line`: `#221D2D`
  • `panel`: `#1D1928`
  • `selection`: `#A78BFA33`
  • `success`: `#8CE0B6`
  • `text`: `#F1ECFA`
  • `textMuted`: `#B6A9C8`
  • `warn`: `#F2CF76`

Default theme names:

  • Human-facing: `Amethyst Night`
  • File/config slug: `amethyst-night`

Universal Mapping Rules

When the target app has different token names, map them by role:

  • Main window/app background -> `background`
  • Secondary surfaces/panels -> `panel`
  • Editor/input surface -> `editor`
  • Active line/hover strip -> `line`
  • Borders/dividers -> `border`
  • Primary text -> `text`
  • Muted text/gutters -> `textMuted` or `gutter`
  • Comments/de-emphasized syntax -> `comment`
  • Keywords -> `keyword`
  • Types/classes/entities -> `entity`
  • Functions/headings/important names -> `entityName`
  • Selection/active region -> `selection`
  • Added/success states -> `added`
  • Warning states -> `warn`
  • Error/removed states -> `error`
  • Info/secondary highlight -> `info`
  • Strong accent/active controls -> `accent`
  • Softer links/operators/string-like accents -> `accentSoft`

Terminal Color Mapping

For terminal emulators and TUI tools with ANSI palettes, use this default mapping:

  • `black` -> `background`
  • `red` -> `error`
  • `green` -> `added`
  • `yellow` -> `warn`
  • `blue` -> `info`
  • `magenta` -> `accent`
  • `cyan` -> `accentSoft`
  • `white` -> `text`

Bright colors:

  • `bright_black` -> `comment`
  • `bright_red` -> `error`
  • `bright_green` -> `added`
  • `bright_yellow` -> `warn`
  • `bright_blue` -> `entity`
  • `bright_magenta` -> `keyword`
  • `bright_cyan` -> `accentSoft`
  • `bright_white` -> `keybind`

Workflow

1. Identify the target app

Extract the app or apps from the user's request.

Common targets include:

  • VS Code
  • Kitty
  • CAVA
  • btop
  • OpenCode
  • Fastfetch
  • other editors or terminal tools

If the user names multiple apps, theme all of them.

2. Inspect the existing config first

Before editing:

  • Find the config file or theme directory with `glob`
  • Read the current config with `read`
  • Follow the app's existing include/import structure instead of replacing it
  • Preserve unrelated settings

3. Choose the right app-specific path

#### VS Code

  • If the user wants a full theme, create or update a theme extension with `package.json` and a theme JSON file
  • Use `Amethyst Night` as the label and `amethyst-night` in filenames where appropriate
  • Theme workbench colors, terminal colors, token colors, and semantic token colors
  • Validate all JSON afterward

#### Kitty

  • Prefer updating the included theme file referenced by `kitty.conf`
  • Theme: background, foreground, cursor, selection, borders, tabs, ANSI colors, bright ANSI colors
  • Preserve font, padding, and other terminal settings unless the user asks otherwise

#### CAVA

  • Update the `[color]` section
  • Set `background` and `foreground` directly
  • Use a 6-step Amethyst gradient unless the existing config clearly uses a different structure
  • Keep audio/input/output settings unchanged

Suggested default gradient:

  • `#473B58`
  • `#84769A`
  • `#AA9ACF`
  • `#A78BFA`
  • `#C49BFF`
  • `#D3C4FF`

#### btop

  • Create a `.theme` file in a directory btop can actually read from
  • Prefer the standard user theme directory if writable: `~/.config/btop/themes`
  • Set `color_theme` to the bare theme name, not an arbitrary file path, when using named theme lookup
  • If the standard themes directory is not writable, place the theme somewhere readable such as `~/.config/btop/` and ensure btop launches with `--themes-dir` pointing there
  • If needed, create a lightweight wrapper in `~/.local/bin/btop` that forwards to `/usr/bin/btop --themes-dir "$HOME/.config/btop" "$@"`
  • If a wrapper is required, ensure `~/.local/bin` is on the user's PATH in their shell config

#### OpenCode

  • Do not put active theme config in `opencode.json`
  • Create a theme file in `~/.config/opencode/themes/amethyst-night.json`
  • Set the active theme in `~/.config/opencode/tui.json`
  • Use the `https://opencode.ai/theme.json` shape with `defs` and `theme`
  • Theme UI colors, diff colors, markdown colors, and syntax colors

#### Unknown or unsupported apps

  • Inspect the app's config format and theme schema first
  • Reuse the same semantic roles instead of directly copying random hexes into unrelated fields
  • Match the app's conventions for naming, includes, and file placement
  • Validate the resulting config if a schema or parser is available

4. Verify

After editing:

  • Validate JSON, TOML, or other machine-readable config when possible
  • Read back the changed file to confirm the active theme setting points at the new theme
  • Note whether the app needs restart, reload, or reinstall steps

5. Report clearly

Tell the user:

  • which files changed
  • whether the theme is already active or only created
  • what command or restart step applies the theme
  • any environment-specific caveat such as a wrapper script or permission issue

Output Standards

When implementing this skill:

  • Prefer exact palette reuse over improvisation
  • Do not introduce extra accent colors unless the target format forces it
  • Keep high contrast between `background`, `panel`, `editor`, and `text`
  • Preserve the calm dark look; do not turn it into neon or pastel mode
  • Keep comments muted, warnings warm, and errors pink-red

Avoid

  • Replacing the user's whole config when a targeted edit is enough
  • Breaking include chains already present in the app config
  • Using absolute theme file paths when the target app expects a theme name
  • Forgetting to validate JSON-based themes
  • Changing fonts, layout, or behavior unless the user asked for that too

Good Outcome

The finished result should feel like the same theme family everywhere:

  • dark
  • soft-amethyst
  • readable
  • low-noise
  • consistent across tools

If there is any doubt between "follow the app's native theme structure" and "force a custom layout," choose the app-native structure.