dsh-deep-whale: two skins, one profile, and a 24 hour publish delay

Two skins and a manager, with two different licences

The repository is a collection of three packages, not one theme. Each has its own npm name and its own directory:

- `@smalltailqwq/dsh-client-ui-skin-maid-atelier`, described as a deep-sea maid workshop with two whale-girl characters, deep blue lace and a chibi sidebar - `@smalltailqwq/dsh-client-ui-skin-orca-link`, described as a cool black-whale operator, a fully rectangular interface and icons redrawn with straight lines, bright on light mode and calming on dark - `@smalltailqwq/dsh-client-ui-skin-deep-whale-manager`, the panel that switches between installed skins, adjusts their options and is opened from Settings

The licence column of that table is the part to read twice. Both skins are MIT for code and CC BY-NC-SA 4.0 for artwork. The manager is MIT only, because it ships no artwork. A non-commercial share-alike term on the images means the art and the code do not travel together under one permission, and the repository's own metadata field reports no licence at all even though a licence file sits at the root.

Attribution is handled in a table of its own. Two artists are credited: one for the original whale-girl character art used by both skins, one for a secondary maid design with added elements. Both have their own pages on two art platforms, and the README asks readers to report problems in issues rather than contacting them.

Installation is one command with three adds

There is no clone step and no manual copying. The npm route is a single chained command:

# Linux / macOS / WSL
dsh plugin --profile web add '@smalltailqwq/dsh-client-ui-skin-deep-whale-manager' && dsh plugin --profile web add '@smalltailqwq/dsh-client-ui-skin-maid-atelier' && dsh plugin --profile web add '@smalltailqwq/dsh-client-ui-skin-orca-link'

The GitHub route uses the same command with a different source and a path fragment per package, which is what lets one repository publish three installable units.

There are separate PowerShell blocks, and the reason is the chaining character: the shell examples join with two ampersands while the PowerShell examples join with semicolons.

One caveat comes before any of it. If you are using a distribution of this host that ships its own skin centre, you are told to install the two skins from that centre instead and not to run these commands, because the two sets of skins are adapted separately and installing both into one profile makes the interface display incorrectly.

After installing you restart the host once, open Settings and use the skin manager to switch. Every later switch takes effect immediately without another restart. The manager itself is described as one you should keep, since switching depends on it.

A 24 hour publish delay that update reports as success

The README compares the two installation sources in a table, and the second row is the interesting one. From npm you get formally released versions with fixed version numbers, and fixes become available about 24 hours after release, because the host's built-in package manager only installs versions that have been published for at least a day. From GitHub you get the newest code on the main branch and fixes become installable as soon as they merge. The network row adds that npm mirrors can be configured and are more stable inside China, while GitHub needs GitHub to be reachable.

The update section explains the delay again and adds the part that matters operationally: a newly published npm version can only be picked up by the update command after 24 hours, and before that the update stops at the previous version and does not report an error. The stated reason is that the host's built-in package manager sets that default delay as a defence against malicious packages.

An update that silently stays where it was is a bad failure mode in a pipeline, so the workaround is spelled out: append a version to the package name and reinstall. The example pins a caret range rather than an exact version, and the README warns in bold-adjacent prose not to omit that caret, because leaving it off fixes the version and later update runs will no longer upgrade anything.

So the same flag means two opposite things depending on whether it is there: with it, you get the newest release now; without it, you get a permanent pin.

Skins declare which host versions they support and are disabled when it moves

Each skin declares the host versions it has been adapted to, currently the 0.1.7 release and the 0.2 series. When the host upgrades past a declared range, the host disables the skin and restores the official interface, and the stated reason is that an outdated skin would otherwise cover controls such as the input box.

This is a design choice worth naming. Rather than letting a skin break the interface after a host upgrade, the compatibility boundary is declared and enforced by the host. The cost is that a skin can stop working the day the host updates, including on a version that changed nothing the skin uses.

There are two escape hatches. In the manager panel a disabled skin shows a message saying it does not declare support for the current host version and was disabled automatically, and you can switch it on and confirm. The override is deliberately narrow: it applies only to that pair of a skin version and a host version, and either side updating causes the check to run again.

The command line version takes three arguments, including the skin version, the host version and a flag that accepts risk:

dsh plugin --profile web allow-version @smalltailqwq/dsh-client-ui-skin-orca-link@<皮肤版本> --dsh-version <DSH 版本> --accept-risk

That last flag is the interesting part of the whole design. It names the override as a risk decision rather than a preference, and it is required.

Absence from the config file means a skin is enabled

The mutual exclusion mechanism is where a new user loses an afternoon, and the reason is one sentence.

Each skin's switch is recorded in two files: one at the profile level and one at the home level, with the home file taking priority. A skin that is not written in the file at all defaults to enabled.

That default is what produces the documented failure. Install two skins and never switch, and nothing records a preference, so both are enabled, both run, and the interface garbles: the settings button disappears, the sidebar width is wrong and decorations overlap.

The manager handles it at startup. If it finds two or more skins enabled it disables them all and returns to the official default, while leaving an already chosen single skin alone. When you switch in the panel, it writes the switch into both files at once and it takes effect immediately.

The manual repair is a YAML block with one entry per skin and a disabled flag, which has to be added to both files simultaneously, with the one you want set to false and the other to true:

- id: ui-skin-maid-atelier
  disabled: false
- id: ui-skin-orca-link
  disabled: true
- id: ui-skin-deep-whale-manager
  disabled: false

One trap is called out: if the file is still the host's default template, a few comment lines and an empty list, you have to replace that empty list rather than append to it, or the file is malformed and the manager cannot do its job.

A local path install fails without an error message

For development, or to test a specific commit, there is a local directory route. It starts with a shallow clone and then runs a script from the repository's own agent skills directory:

git clone --depth 1 https://github.com/Small-tailqwq/dsh-deep-whale
node <clone 的绝对路径>/.agents/skills/dsh-skin-install/scripts/stage-mutual-exclusion.mjs --profile web --target maid-atelier
dsh plugin --profile web add <clone 的绝对路径>/skin-manager

That script is optional. It pre-selects the default skin so the first launch is already themed, and its target can be either skin or the official default. Skip it and you get the official interface on first launch, then switch in the panel.

The notes after it are the useful part, because three of the four failure modes are silent.

Use absolute paths, either slash style on Windows. Do not pass a bare directory name: the argument is treated as an npm package name, downloaded, and returns a not found. Relative paths have to start with a dot and they resolve against the directory you ran the command in, not against the skin repository. And if you get a path wrong the command does not error, the skin simply does not take effect.

A local directory, an npm install and a GitHub install all use the same package name, so the last add wins.

The old package scope has to be removed or you keep two copies

Anyone who installed from GitHub before version 0.1.3 has a migration to do, and the failure it prevents is specific.

Those early GitHub installs used a different package scope entirely. The README asks you to remove the three old packages first, and gives the commands:

dsh plugin --profile web remove '@dsh-external/dsh-client-ui-skin-orca-link'
dsh plugin --profile web remove '@dsh-external/dsh-client-ui-skin-maid-atelier'
dsh plugin --profile web remove '@dsh-external/dsh-client-ui-skin-deep-whale-manager'

Install without removing them and the host ends up holding two copies of the same plugin, because the old scope and the new one are different package names to the plugin manager even though they are the same code. Then you install the new set and restart once.

The reassuring detail is at the end: the skin you had selected and your settings are preserved, and are unaffected by the package name change.

That whole class of problem comes from installing by directory path or by branch rather than by published name. The rest of the troubleshooting section is built on the same principle. A broken interface is nearly always two skins running, and switching to the official default and refreshing restores it. An install that appears to do nothing is a browser cache issue first, then a check that the target skin is actually enabled in the panel.

Every release note is a compatibility statement

The three most recent releases read as a compatibility log rather than a feature log.

The newest is version 0.1.7, adapted to a 0.2.0 release candidate of the host, with the input box moved to the bottom and performance work. Before that, 0.1.6 adapted to a 0.1.7 release candidate and added native control skin management along with performance work. Before that, 0.1.2 adapted to a 0.1.5 release candidate with settings and interaction improvements.

So each release names the host version it targets, and the declared support ranges in the documentation are the 0.1.7 release and the 0.2 series. The last push to the branch was 2026-10-03.

The repository is also multilingual in a practical way. There are three readmes, one each for simplified Chinese, English and Vietnamese, and the English and Vietnamese ones are separate files rather than translations maintained in place.

Two files round out the structure. One is an install document written to be read by an agent: the README suggests pasting a sentence into any assistant, including the host itself, telling it to read that document from the repository and follow its instructions, which is a compact way of saying the installation is a specification someone else can execute. The other is a todo file, and the directory layout also carries a shared directory for what the two skins have in common, a documentation directory, a scripts directory and the agent skills directory the local install script lives in.

Editorial conclusion

Adopt this pack if you want a themed interface for DeepSeek Harness and will follow its release notes, because each release exists to match a specific host version and the two ships update together. Do not install both skins and expect them to coexist, because the manager's first action is to disable both, and the underlying reason is that an absent entry in the configuration means enabled. Before you install, read the version declaration: a skin that does not declare your host version is switched off automatically, and the override that re-enables it requires an explicit risk acceptance flag. And if you redistribute any of this, keep the two licences apart, since the code is MIT while the artwork is CC BY-NC-SA 4.0 and belongs to two named artists.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Small-tailqwq/dsh-deep-whale on GitHub