tevenfeng/dsh-plugin-omoslim

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):

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:

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

1. Remove the bundle: dsh plugin --profile web remove dsh-plugin-omoslim (or drop the dependency + dsh.profile.bundles entry manually), restart.
2. 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