Model Commands (@fufu1437/dsh-model-commands)
A DeepSeek Harness (DSH) plugin that lets you author your own skills in the
Settings page.
Every entry you write is published into the Harness skill registry, so it
behaves exactly like a shipped skill: the model's catalog carries one line
(name + description), the built-in skill tool loads the body only when it
is needed, and the plugin executes nothing — a skill is text the model reads,
never a command that runs.
中文文档：README.zh.md
Why skills rather than tools
DSH already ships the deferred-loading machinery: a skill catalog costs one line
per entry on every request, and the body is paid for once, when the model asks
for it. This plugin adds a table, a Settings page, and a registry provider on
top of that — it registers no tools of its own, so there is nothing new for the
model to learn and nothing to keep in sync with the harness.
| Declared here | Shipped skills (a skills folder) |
|---|
| Where it lives | <DSH_HOME>/model-commands/skills.json | files on disk |
| Who edits it | Settings → Model commands | your editor |
| Model-facing behaviour | identical | identical |
The page
Settings → Model commands shows one card per entry — the name, badges
(user/model, disabled, only you), the description, and a text action row
(Edit / Disable / Delete). The round + in the top right opens the
editor:
| Field | Meaning |
|---|
| Name | kebab-case (disk-usage); the key the model loads. |
| Description | Required. The only thing in the standing catalog, and the whole basis for the model's decision. |
| When to use | Optional extra trigger text, carried in the catalog too. |
| Body | Markdown the model receives after loading. A pasted --help output is fine (up to 65 536 characters). |
| Model can invoke | On by default: the entry appears in the model's skill catalog. |
| You can too | Off by default: additionally lists it on the human command surface. |
| Enabled | Off keeps the entry stored but out of the catalog. |
Saving writes the whole table atomically, re-publishes it, and invalidates the
skill catalog, so the change is visible to the model on its next step — no
restart, no reload.
Validation is the Host's, and the page renders its diagnostics: errors (bad
name, missing description or body, oversized body, duplicate name) block the
save; warnings (a name another provider already publishes, an entry only you
can invoke) appear as a dismissible banner and never block.
Configuration
- id: fufu-model-commands
name: '@fufu1437/dsh-model-commands'
config:
storePath: /home/me/.dsh/model-commands/skills.json
maxSkills: 200
| Field | Default | Meaning |
|---|
storePath | <DSH_HOME>/model-commands/skills.json | Where the table lives. |
maxSkills | 200 | Entry ceiling. |
Install
DSH 0.2.x, whose profiles are pnpm-managed. engines.dsh declares
>=0.2.1-rc.2 <0.3.0, which the 0.2.1 plugin manager checks before it installs
or activates the bundle.
Inside the Harness, one install_bundle call adds the profile dependency,
selects the bundle layer, and reloads the live profile:
install_bundle target: @fufu1437/dsh-model-commands
target: link:/absolute/path/to/dsh-model-commands # developing
From a shell, the two steps the manager performs:
dsh plugin --profile web add @fufu1437/dsh-model-commands
# then select the bundle: Settings → Plugins, or append the package name to
# dsh.profile.bundles in ~/.dsh/profiles/web/package.json
Refresh the Web page so the browser half loads.
After a DSH update
An upgrade can rebuild the profile and drop third-party bundles: the dependency
and its dsh.profile.bundles entry disappear even though cordis.patch.yml
survives, so the plugin silently stops loading. Re-run the install step above;
the table at <DSH_HOME>/model-commands/skills.json is never touched.
Iterating on the plugin
npm run check && npm test exercises the pure logic without a Harness.
client.js is read from disk by the client-module registry: reload the
plugin row (flip the entry's disabled in <profile>/cordis.patch.yml,
true then false) and refresh the page.index.js needs module watching or a Harness restart. On this machine the
profile already enables watching for this directory (hmr with
base = the plugin directory, root: ["."]), so a saved index.js reloads
itself.
Behaviour and limits
- Nothing is executed. The plugin reads and writes one JSON file, publishes
skills, and serves two fenced routes. There is no shell, no sandbox, no
evaluation of user code.
- The table is the single source of truth; the published catalog is derived, so a
save persists first and re-publishes in the same step.
- Writes are atomic (temporary file + rename), and one invalid row is reported
without discarding the valid ones.
- Both routes pass the composition's
connection.requestRejection trust fence
first; unauthenticated requests get 401/403.
- The package imports only
node: builtins — no @deepseek-ai/* dependency — so
it publishes as an ordinary npm package and does not break when harness
internals move.
- A name another provider already publishes is a warning, not an error: the
registry settles the collision by layer and rank, so one of the two shadows the
other.
Migration from 0.2.x
Up to 0.2.0 an entry declared a command line and the plugin registered one
model-facing tool per entry. That is gone: an entry is a skill now, stored in
skills.json. An old commands.json is left untouched and no longer read —
paste its text into the new editor if you want it back, or, for a folder of
files, use the built-in filesystem skill roots instead (for example
~/.dsh/skills/).
Not yet (next iterations)
- Model-authored entries (a
skill_create-style toolset behind the user's
approval), mirroring how dsh-custom-tool lets the model grow its own tools.
- Import/export and reordering.
- Per-project scoping (the provider already receives the view's
cwd, so this is
a storage decision, not an API one).
