dsh-deep-whale: Whale Girl Skins for the DeepSeek Harness Web GUI

What dsh-deep-whale Actually Ships

This is not a standalone application. It is a separately distributed skin series for the DeepSeek Harness Web GUI, and the repository holds three packages rather than one. Two are skins: maid-atelier, published as @smalltailqwq/dsh-client-ui-skin-maid-atelier, described as a deep-sea maid workshop with a double-maid background and a Q-style sidebar, and orca-link, published as @smalltailqwq/dsh-client-ui-skin-orca-link, described as a pearl-white mechanical cabin with an orca girl character and electric-blue link signals. The third is skin-manager, @smalltailqwq/dsh-client-ui-skin-deep-whale-manager, which is not a skin at all. It provides skin discovery, switching and a self-declared configuration panel.

The audience is narrow and specific: people already running the DeepSeek Harness Web GUI who want a themed interface and are willing to install plugin packages into a DSH profile. If you do not run DSH, none of this applies to you. The README is explicit that the packages install without cloning the repository, so the entry cost is three commands plus one restart. Each skin ships preview images for both light and dark mode in its own preview directory, so you can judge the look before touching a profile.

The repository layout reinforces the separation. The top level holds the two skin directories, skin-manager, scripts, and the documentation files README.md, README.en.md and README.vi.md, plus INSTALL.md and AGENTS.md. The skins are not vendored into the manager; they are siblings that the manager discovers.

Licensing Is Split Between Code and Artwork

The repository's licence field is NOASSERTION, but the README gives a per-package breakdown that matters more than the top-level metadata. Both skins are MIT for code and CC BY-NC-SA 4.0 for artwork. The skin manager is MIT only. That split is the practical detail: the non-commercial clause attaches to the illustrations, not to the TypeScript that wires them into the interface.

The README also names the copyright holders. 上善 is credited as the original creator of the whale girl character design used by both skins, and ZipZipPipe is credited with the maid whale girl redesign that incorporates DeepSeek elements for maid-atelier. The README asks that problems be filed as issues rather than sent to those two artists, while noting that following them is fine if you want to see more whale girl fan work. If you plan to redistribute a build that embeds the artwork, the CC BY-NC-SA 4.0 terms are the ones to read, not the MIT terms. This is a description of what the repository states, not legal advice.

Why Two Skins at Once Break the Interface

The design problem this project solves is not cosmetic. DSH skins are enabled or disabled through a patch layer, and the README describes the rule bluntly: if a patch file contains no disabled line for a given skin, that skin is enabled by default. Install both skins at once and never switch, and both run simultaneously. The decorations stack, the sidebar and settings area get tangled, and the documented symptoms are a vanished settings button, abnormal sidebar width or layout, and a generally confused interface. The stock interface, by contrast, is fine.

Mutual exclusion is enforced by the skin manager as a fallback. When all three packages are registered by the one-line install, the manager merges the profile and home layer states on first restart. If it detects two or more skins actually enabled, it automatically and atomically rolls back to the official default and writes the exclusion lines. A legal existing state of zero or one enabled skin is left untouched. That is the real mechanism worth understanding here, and it is more interesting than the colour scheme.

Note what the fallback does not do. It does not merge two skins into one coherent theme, and it does not ask you which one you meant. It reverts to the official default and hands the decision back to you through the manager panel. The README also stresses that the manager itself is not a skin and must stay enabled, because switching and exclusion both run through it.

Installing dsh-deep-whale and Switching a Skin

The README's recommended path is a one-line install from npm, and it warns first that the command applies only to a standalone environment running DSH directly. If you installed @linxin666/dsh-web-all, use that distribution's own skin center instead and do not stack this repository's standalone packages into the same profile. On Linux, macOS or WSL, the three packages are added in sequence:

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'

On PowerShell the same three commands are separated by semicolons instead of &&:

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'

If you only want one skin, delete the line you do not need; the README suggests keeping skin-manager because switching and exclusion both depend on it. The first install adds new plugin packages, so DSH needs one restart. During that restart the manager detects two simultaneously enabled skins and atomically rolls back to the official default, which means a first install never shows the stacked-skin window. After that, open Settings, then Skin Management, and click Switch on the target skin. The change hot-reloads, and later switches need no restart and no AI involvement.

The README also documents an update command for when the packages move:

dsh plugin --profile web update @smalltailqwq/dsh-client-ui-skin-deep-whale-manager @smalltailqwq/dsh-client-ui-skin-maid-atelier @smalltailqwq/dsh-client-ui-skin-orca-link

Bundle content updates travel through configuration hot reload; only adding or removing plugin packages requires a restart. Running the update command without package names updates every dependency in the profile, which has the same effect when these skins are the only ones installed. There is also a migration path for anyone who installed from GitHub before 0.1.3, when the dependency keys used the @dsh-external/* placeholder scope. Those three keys must be removed before running the npm install, otherwise DSH may retain two sets of plugin identities at once.

The Patch Layer and Its YAML Trap

Skins are toggled by writing disabled lines into two patch files, and the README is emphatic that both are required: ~/.dsh/profiles/web/cordis.patch.yml and ~/.dsh/cordis.patch.yml, with the home layer taking priority. The manager writes these lines automatically when it activates, but the manual route is documented, and it carries a trap worth repeating. If a patch file is still the default DSH template, meaning comments plus a single [] line, you must replace that [] line with the whole list. A file containing comments, [] and additional entries is invalid YAML and configuration parsing fails. The README notes the server keeps running on the last usable configuration, so the failure is survivable but confusing until you fix the file and refresh.

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

Only one skin line may be false. If you hand-write this, you must explicitly disable every other skin; there is no implicit exclusion in the patch layer itself. The README's framing is that the manager exists precisely so you do not have to keep this state correct by hand, and that hand-editing is the fallback when the manager is unavailable or a configuration has already been written badly.

Relative Paths, Bare Directory Names and Local Links

The local development path is where most of the friction lives, and the README treats it as a separate section for exactly that reason. Relative paths beginning with ./ or ../ resolve against the directory where the dsh command was invoked, not the skin repository. A bare directory name is worse: dsh plugin --profile web add maid-atelier is treated as an npm package name, goes to the registry, and fails with a 404. You need ./maid-atelier from inside the repository, ../dsh-deep-whale/maid-atelier if the two directories are siblings, or an absolute path. The sibling case is the one that bites silently: if you cloned elsewhere, the relative path links to the wrong location, the command reports no error, and the skin simply does not take effect. The README's advice is to use an absolute path when unsure.

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
dsh plugin --profile web add <clone 的绝对路径>/maid-atelier
dsh plugin --profile web add <clone 的绝对路径>/orca-link

The staging script sets the target skin as the only enabled one before plugin add runs, so the first start lands directly on the chosen skin. It accepts --profile web and --target maid-atelier, orca-link or official, and preserves non-skin YAML rather than overwriting the whole patch file. Skipping it is safe, because the manager fallback still applies. The README also points at INSTALL.md as the standard entry point for AI-assisted installation, which routes through a bundled dsh-skin-install skill; the skill handles old-install migration, local development and cold-start verification, and the plain install case still reduces to the same one-line command.

When dsh-deep-whale Is the Wrong Tool

The clearest wrong-tool case is written into the README itself. If you installed @linxin666/dsh-web-all, do not install these standalone packages at all. The README states that the component and style contracts differ, and mixing them in one profile can produce display problems; you are supposed to use the skin center that dsh-web ships, which has maid-atelier and orca-link adaptations. That is a hard boundary, not a preference.

The second limitation is structural. This repository is decoration. It does not change how the harness works, and its only functional component, the skin manager, exists to arbitrate between skins. If you never wanted a themed interface, nothing here is for you.

The third is maintenance shape. The release notes show v0.1.1 adapting to DSH 0.1.2 RC1 and v0.1.2 adapting to DSH 0.1.5 RC1, which means skin compatibility tracks harness release candidates. Expect to re-run the update command when the harness moves, and expect the packages to lag a harness RC rather than lead it. A skin that breaks against a new harness RC is a cosmetic failure, but a broken patch layer is not: the README's symptom list, a missing settings button and a distorted sidebar, describes an interface you may not be able to navigate back out of through the UI alone.

How This Differs from Editing the Harness Directly

The obvious alternative is not another skin pack. It is patching the harness's own client UI, or writing your own skin against the DSH plugin API, which is the same work this repository did. The difference in approach is packaging and arbitration. A hand-patched harness has no separation between code and artwork, no npm dist-tag to follow, and no manager deciding which skin owns the interface. This project keeps the skins as independent npm packages under one scope, publishes them separately from the harness, and puts the conflict resolution in a persistent third package. That third package is the actual product decision: it accepts a permanent resident plugin in exchange for never having to reason about patch-layer state by hand.

A second alternative, for anyone who only wants one look, is to install a single skin and skip the manager. The README says this works, because a skin with no disabled line is enabled by default. You give up switching and the automatic fallback, and you take on the responsibility of keeping the patch layers consistent yourself. That is a reasonable trade for a single-skin setup, and a bad one the moment you want to compare the two looks.

Maintenance, Updates and What to Verify First

Upgrade cost is low but not zero. npm dependencies follow the latest tag by default, and the update command re-resolves whatever that tag currently points to; GitHub dependencies re-resolve the latest commit instead. Content updates hot-reload, package additions and removals need a restart. Skin preferences are stored by skin id, maid-atelier or orca-link, so they survive an npm scope rename, which is why the @dsh-external/* migration does not lose your choice.

The last push to the repository was on 2026-09-15, and the repository is not archived. Before installing, confirm which DSH distribution you are running, since that single fact decides whether these packages are the right ones. Then check your existing patch files for leftover @dsh-external/* keys if you installed from GitHub before 0.1.3, and confirm the two patch layer paths exist. If the settings button disappears or the sidebar layout goes strange after installing, the README's recovery order is: use Settings, then Skin Management, and click Official Default or any skin; if the manager is unavailable, run stage-mutual-exclusion.mjs with --target official; or remove the unused package with dsh plugin --profile web remove.

Editorial conclusion

Adopt dsh-deep-whale if you run a standalone DeepSeek Harness Web GUI and want a themed interface without patching the harness yourself; the three packages install through dsh plugin and the skin manager handles switching. Do not adopt it if you installed the harness through @linxin666/dsh-web-all, since the README states you should use that distribution's own skin center instead, and do not stack both sources in one profile. Before installing, verify which distribution you are on, and if you installed from GitHub before 0.1.3, remove the three @dsh-external/* keys first so DSH does not keep two plugin identities.

Frequently asked questions

Official sources

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