DeepSeek Harness Skills: DSH plugin skill tool and merging

DeepSeek Harness skills are optional, load-on-demand instructions rather than session events: providers register local or bundled skills into ctx.skills, the registry merges directories across the host layer and scope layers, and the model-facing skill tool loads and invokes them by cwd (source). For where they live and their priority, see Where DeepSeek Harness Skills are discovered; this article covers how they are invoked and merged.

What a DeepSeek Harness skill is

A skill is an optional instruction, not a session event, so its vocabulary definitions are not in core; the model fetches it on demand instead of stuffing it into context every turn (source). Key implications:

1. Loaded on demand — once providers register, whether to load is decided at call time. Expected: unused skills consume no model attention.
2. Not part of session history — it travels a different channel from session events. Expected: querying session history will not show skill contents as events.
3. It can come from many sources — local directories, bundled packages, and in-process providers can all contribute. Expected: one deployment may have several skill sources at once.

To find community plugins that ship skills, browse DSH Plugin Hub.

Who provides DeepSeek Harness skills: ctx.skills and its providers

The skill family has a service definition, several service providers, and one Consumer: the definition is dsh-skill (ctx.skills) and the Consumer is dsh-tool-skill (the model-facing skill tool) (source). Meet them one by one:

1. dsh-skill (definition) — defines ctx.skills and the related vocabulary. Expected: it is where all providers register.
2. dsh-skill-filesystem (local provider) — contributes skills from filesystem directories. Expected: skills in your local directories are discovered by it.
3. dsh-skill-badge, dsh-skill-office (bundled providers) — ship skills with a package. Expected: installing the package gives you its skills without writing your own.
4. sandbox-windows-acl (diagnostic provider) — provides Windows ACL diagnostic skills. Expected: useful when troubleshooting on Windows.
5. dsh-tool-skill (Consumer) — owns the initial and replacement directories and exposes the model-facing skill tool. Expected: the model gets skills through it.

SkillProvider registers synchronously during apply(), while remote initialization, authentication, and discovery happen asynchronously inside list(); SkillProviderObservation lets a provider declare whether a discovery pass is authoritative (complete), distinguishing a cacheable full result from a partial result from incomplete discovery.

How DeepSeek Harness skill directories merge: host and scope layers

The registry uses a host-plus-scopes overlay: reads merge the host layer with the scope's chain; the narrowest layer's entry wins a same-name skill outright, and rank order only decides priority within one layer (source). How to think about it:

1. Two-layer structure — the host layer and scope layers each hold directories, merged along the scope chain on read. Expected: a layer closer to the current work overrides a same-name skill from an outer layer.
2. Within a layer, rank decides — inside one layer, priority follows rank, provider order, then local order. Expected: intra-layer conflicts have a definite rule, not randomness.
3. De-duplicated by name — a same-name skill resolves to the narrowest layer. Expected: to override a skill temporarily, put a same-name version in a narrower scope.
4. Concrete directories and rank numbers — the six local sources (project-dsh, project-agents, custom, user-dsh, user-agents, bundled) and their ranks are in Where DeepSeek Harness Skills are discovered.

How a DeepSeek Harness skill is invoked and refreshed

The model invokes skills through the skill tool with lookup options such as cwd; when content changes, providers emit a skills/change invalidation event carrying no diff, so consumers must re-fetch snapshot() themselves (source). Usage points:

1. Call with cwd — among lookup options, cwd selects workspace-related skills. Expected: the same skill name may resolve differently across workspaces.
2. The provider's get() loads the body — for a listed candidate, the provider fetches full content with get(candidate, options); when no longer loadable it returns undefined. Expected: candidates can go stale, so handle the not-found case.
3. Changes go through invalidation, not increments — the skills/change event carries no diff, and invalidate() clears the completed directory and notifies consumers. Expected: re-pull after a change; do not expect the event to carry the changed content.
4. Failures are isolated per provider — when a provider's list() is rejected it is logged and that provider's results are removed from the complete observation; malformed candidates fail fast. Expected: one failing source does not pollute the whole skill list.

Notes and common questions

1. A skill is not a session event: session history will not show skill contents; do not conflate the two.
2. Same-name resolution is by layer, not cross-layer rank: cross-layer override follows "narrowest layer wins", and rank applies only within a layer.
3. Be careful caching complete: false: an incomplete discovery result may be only a partial candidate set.
4. Re-pull after edits: the invalidation event carries no diff, so the consumer re-fetches the snapshot.
5. Skills are plugin-contributed capabilities: if you cannot find the one you want, look at community plugins on DSH Plugin Hub, or see What built-in tools DeepSeek Harness has.

Sources: Skills (official docs), Tool schema catalog (official docs)