dsh-plugin-omoslim
DeepSeek Harness (dsh) bundle that installs an Orchestrator agent preset
in the style of oh-my-opencode-slim:
the main agent plans and dispatches, and model-pinned specialist subagents do
the work.
What you get
One agent preset, orchestrator:
- Main agent = Orchestrator — a workflow manager persona (plan → dispatch →
reconcile → verify), delegating instead of implementing.
- 11 subagent tools, each with its own persona and a model slot in a
named model profile under
models.d/ (provider defaults to null, i.e.
inherit the main agent's provider):
| Tool | Role | Model |
|---|
subagent | generic worker (background, continuable) | inherit |
subagent_fork | forks parent context | inherit |
subagent_explorer | fast codebase navigation (read-only) | deepseek-v4-flash |
subagent_oracle | architecture / review advisor (read-only) | glm-5.2 |
subagent_librarian | docs / external research | minimax-m2.7 |
subagent_designer | frontend UI/UX | kimi-k2.6 |
subagent_fixer | bounded implementation | deepseek-v4-flash |
subagent_councillor_alpha/beta/gamma | independent multi-model reviews | glm-5.2 / kimi-k2.7-code / qwen3.7-max |
subagent_council | multi-model consensus synthesis | kimi-k3 |
The models above mirror the OMO opencode preset found in
~/.config/opencode/oh-my-opencode-slim.json. The OMO council model
gpt-5.6-luna is not in the opencode-go catalog, so kimi-k3 is used.
All model and provider names are examples from the OMO author's
environment. The factory profiles seed provider: null (the subagent
inherits the main agent's provider); set provider in models.d/<name>.json
to pin one (e.g. "opencode-go"), and make sure each model name exists in
that provider's catalog.
How it works
A dsh bundle is an npm package declaring
"dsh": { "bundle": { "patch": "./cordis.patch.yml" } }. This bundle's patch
layer inserts one row: the preset-installer plugin. On boot the plugin
installs/updates config/presets/* in the harness-home user preset root
(~/.dsh/.agent-presets), which the agent-presets roster always scans.
Why install into the user root instead of registering a new root? The dsh
launcher's composeProfile forcibly overwrites agent-presets.config.roots
with the shipped root, so a bundle cannot contribute its own root. The user
root is the supported extension path.
Model definitions are separated from the composition
Each subagent's model and persona live in different files on purpose —
you are far more likely to tweak a model than a persona, and plugin updates
should not clobber your model choices. On top of that, you can keep many
named model profiles and switch the active one at any time:
| File (in the bundle) | File (in ~/.dsh/.agent-presets/orchestrator/) | What you edit |
|---|
config/models.d/*.json | models.d/*.json | factory profiles (seeded on install; user-editable afterwards) |
| — | models.d/default.json | the default profile (user-owned) |
config/presets/orchestrator/agent.cordis.yml.tmpl | agent.cordis.yml (rendered) | personas / tool wiring (generated from template) |
| — | .generated | render stamp { active, sourceHash, renderedHash } (managed) |
The active profile is stored in ~/.dsh/settings.yaml under
omoslim.active (defaults to default). Every boot the plugin re-renders
agent.cordis.yml from the current template + the active profile. Rules:
- Switch the active profile →
omoslim switch <name> re-renders
agent.cordis.yml in place. dsh mounts each preset's composition once per
process, so restart dsh (or the dsh-web service) for the new models
to load, then create a new session.
- Model / provider change → edit
models.d/<name>.json
(provider: null = inherit the main agent's provider), then switch to it.
- Plugin update (new personas/wiring) → re-render happens on next boot;
your
models.d/*.json profiles are never overwritten.
- Hand-editing the composition → if you edit
agent.cordis.yml directly,
the plugin detects it (hash differs from the stamp) and leaves your file
alone. You own it then; delete the preset directory to take plugin updates.
A profile must name every slot the template references (explorer, oracle,
librarian, designer, fixer, councillor_alpha, councillor_beta,
councillor_gamma, council). A missing slot fails closed rather than rendering
a half-populated composition.
Install
# from the profile directory (web is the default profile)
dsh plugin --profile web add dsh-plugin-omoslim
dsh plugin forwards to pnpm and reconciles dsh.profile.bundles, so the
package is both installed and activated as a bundle layer. Then restart the
web app:
systemctl --user restart dsh-web
# or: restart your `dsh web` process
For local development instead of a published package:
# in ~/.dsh/profiles/web/
pnpm add file:/home/<you>/Coding/dsh-plugin-omoslim
# then add the package name to the "dsh.profile.bundles" array in package.json
Use
Open the web UI, start a new session and pick the orchestrator preset in
Settings → General (it becomes the default only if you set it, or if
~/.dsh/settings.yaml has agent-presets.default: orchestrator). The main
agent will plan and dispatch; the subagent tools appear in its tool catalog.
Subagent model inspector
In the web UI, click the plugin's button to the left of the model selector
(a stack/panel icon). It opens a panel showing the active profile's
per-subagent provider/model at a glance:
- Each row lists one subagent slot with its model, plus the provider when one
is pinned.
provider: null (shown as "inherits main agent") means that subagent uses
the main agent's provider.
The button is shown only while the current session runs the orchestrator
preset — under dsh's own presets or third-party presets these subagent slots
don't exist, so the inspector hides instead of showing misleading data. It is
also hidden on the blank new-session screen (a preset pick there is only
staged, not applied, so the button appears once the orchestrator session
actually starts running).
The data is served read-only by
GET /dsh-plugin-omoslim/subagent-models (JSON), so the panel reflects what
the orchestrator preset is literally composed with. Switching the active
profile (omoslim switch <name>) and opening the panel again shows the new
mapping.
After updating the plugin, restart the web app so the new route and button
are picked up — systemctl --user restart dsh-web, or restart your dsh web
process — then refresh the page.
Uninstall / rollback
- Remove the bundle:
dsh plugin --profile web remove dsh-plugin-omoslim
(or drop the dependency + dsh.profile.bundles entry manually), restart.
- The preset files stay in
~/.dsh/.agent-presets/orchestrator/ — delete
that directory to remove them, or keep it to keep using the preset without
the plugin.
Multiple model profiles
Each profile is one JSON file under
~/.dsh/.agent-presets/orchestrator/models.d/, holding a slot → mapping table:
{
"oracle": { "provider": null, "model": "glm-5.2" },
"explorer": { "provider": "opencode-go", "model": "deepseek-v4-flash" }
}
provider: null (or omitted) = inherit the main agent's provider.- The legacy flat format
"oracle": "glm-5.2" still works.
- Create a new profile by copying an existing file:
cp models.d/default.json models.d/economy.json, then edit it.
Manage profiles with the CLI:
omoslim list # list profiles; the active one is marked *
omoslim current # print the active profile name
omoslim switch economy # switch + re-render now
omoslim ships as an npm bin (declared in package.json). Installing the
plugin also links it into the profile's node_modules/.bin/, but that
directory is not added to your shell $PATH automatically — npm/pnpm bins
never modify your shell config. Make omoslim callable from anywhere with one
of these:
Option A — add the profile's bin dir to your PATH (one line, persistent):
# zsh (default on macOS):
echo 'export PATH="$HOME/.dsh/profiles/web/node_modules/.bin:$PATH"' >> ~/.zshrc
source ~/.zshrc
# bash:
# echo 'export PATH="$HOME/.dsh/profiles/web/node_modules/.bin:$PATH"' >> ~/.bashrc
# source ~/.bashrc
Option B — install the package globally (bin lands on your global PATH):
npm install -g dsh-plugin-omoslim
# then `omoslim` works everywhere; note the global copy is separate from the
# profile's copy, so re-run this after upgrading the plugin.
Option C — one-off, no PATH changes:
~/.dsh/profiles/web/node_modules/.bin/omoslim list # full path
# or, from inside the profile directory:
# npx --no-install omoslim switch economy
omoslim switch <name> writes omoslim.active to ~/.dsh/settings.yaml and
re-renders agent.cordis.yml in place. Because dsh mounts a preset's
composition once per process, the running process keeps the models it was
composed with — restart dsh (or the dsh-web service), then create a
new session to use the new models.
Customizing
-
Change a subagent's model / provider → edit
~/.dsh/.agent-presets/orchestrator/models.d/<name>.json, then
omoslim switch <name> (or let the next boot re-render it). Your profiles
are never overwritten by plugin updates.
{
"oracle": { "provider": null, "model": "glm-5.2" },
"explorer": { "provider": "opencode-go", "model": "deepseek-v4-flash" }
}
provider: null (or omitted) = the subagent inherits the main agent's
provider. The legacy flat format "oracle": "glm-5.2" still works
(provider is treated as inherited). Model names must exist in the chosen
provider's catalog.
-
Change personas / tool wiring → edit the template in the bundle
(config/presets/orchestrator/agent.cordis.yml.tmpl) and bump the plugin,
or hand-edit the rendered ~/.dsh/.agent-presets/orchestrator/agent.cordis.yml
— hand edits are detected (stamp mismatch) and left alone. To take plugin
updates again, delete the preset directory first.
-
Reinstall the pristine preset → rm -rf ~/.dsh/.agent-presets/orchestrator
and restart dsh.
Layout
dsh-plugin-omoslim/
├── package.json # dsh.bundle.patch declaration + "omoslim" bin
├── cordis.patch.yml # bundle patch layer (inserts the installer row)
├── config/
│ ├── models.d/ # factory model profiles (default.json, cheap.json, …)
│ └── presets/orchestrator/
│ ├── preset.yml
│ └── agent.cordis.yml.tmpl # composition template (@@models.<key>@@ slots)
└── lib/
├── index.js # Cordis plugin: installer + template renderer + profile helpers
└── cli.js # omoslim CLI: list / switch / current
