--- name: amethyst-theme description: 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. license: MIT compatibility: opencode metadata: audience: developers --- 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.