omdp — only my DSH plugins

A single GitHub repo that collects all of my DeepSeek Harness (DSH) plugins as a monorepo. Each plugin lives in its own subdirectory and is an independently installable DSH bundle.

Layout

omdp/
├── README.md            # this file
├── package.json         # root manifest — keeps bare-git installs functional (see below)
├── dsh-connector/       # unified MCP + Skills manager (Web UI settings tab)
│   ├── index.js         # host half
│   ├── client.js        # client half (Web UI)
│   ├── cordis.patch.yml # bundle activation row
│   ├── package.json
│   └── README.md
├── dsh-vision-bridge/   # vision bridge: let text-only models "see" via a configured multimodal endpoint
│   ├── index.js         # host half
│   ├── client.js        # client half (paste/drop → temp path)
│   ├── cordis.patch.yml # bundle activation row
│   ├── package.json
│   └── README.md
├── dsh-gitbash-win/     # global Git Bash tool for Windows (POSIX shell for the model)
│   ├── lib/
│   │   ├── index.js     # host half (dynamically loads @deepseek-ai/* at apply time)
│   │   └── client.js    # client half (toolview terminal card)
│   ├── cordis.patch.yml # bundle activation row
│   ├── package.json
│   └── README.md
├── _skeleton-client/    # copy-paste template: client + host bundle (Web UI plugin)
├── _skeleton-host/      # copy-paste template: host-only bundle
├── docs/                # research notes, e.g. AI-DSH-plugin-quality.md (community findings)
└── <future plugins>/    # each its own subdirectory + package.json

Plugins

dsh-connector → npm name @omdp/dsh-connector

One settings tab ("Connector") that manages two things from the DSH Web UI:

• MCP servers — edits the MCP block in cordis.patch.yml (stdio / streamable-http). Legacy SSE servers (e.g. Zhihu) are kept as mcp-remote --transport sse-only stdio bridges; this plugin only manages that config text.
• User skills — read / write / delete skills under ~/.dsh/skills/<name>/SKILL.md.

Install into a profile via a local link: dependency (see its README for the exact steps):

"@omdp/dsh-connector": "link:D:/WorkSpace/omdp/dsh-connector"

dsh-vision-bridge → npm name @omdp/dsh-vision-bridge

A zero-dependency plugin that gives text-only models vision: it auto-detects whether the routed model supports images, and for text-only models forwards pasted / attached images to a configurable OpenAI-compatible multimodal endpoint (default Agnes agnes-2.5-flash) and feeds the returned text back as evidence. Ships a vision_bridge_read_image tool, a paste/drop → temp-path browser handler, a wrapped (vision bridge) provider entry, and an agent/pre-step auto-read hook.

Install into a profile via a local link: dependency:

"@omdp/dsh-vision-bridge": "link:D:/WorkSpace/omdp/dsh-vision-bridge"

See its own README.md for the full config reference.

dsh-gitbash-win → npm name @omdp/dsh-gitbash-win

A lightweight global Git Bash tool for Windows. Registers a gitbash model tool that runs every command via Git for Windows bash.exe (bash -c), giving the model a real POSIX shell (grep/sed/awk/pipes/globs) without WSL and without node-pty. Sandbox-aware, with timeout / background jobs / output-spill / a toolview terminal card. On Windows, Git Bash is the recommended shell for the model: POSIX semantics transfer well to Linux and macOS.

Install into a profile from npm:

dsh plugin --profile web add @omdp/dsh-gitbash-win

Requires Git for Windows installed (C:\Program Files\Git\bin\bash.exe). See its own README.md for config, sandbox notes, and troubleshooting.

Remote installs from GitHub (alternative)

Each plugin is a standalone npm package in its own subdirectory, so it can also be installed straight from GitHub without a local checkout:

dsh plugin --profile web add github:XJungit/omdp#path:dsh-connector
dsh plugin --profile web add github:XJungit/omdp#path:dsh-vision-bridge
dsh plugin --profile web add github:XJungit/omdp#path:dsh-gitbash-win

The #path:<subdir> selector tells pnpm which workspace subdirectory to install (it resolves to that subpackage's package.json, not the repo root).

pnpm ≥10 build-script gate. A git install fetches sources, and pnpm refuses to run a git dependency's prepare/build scripts until explicitly allowed — the first add fails until you whitelist it in the profile's pnpm-workspace.yaml:

allowBuilds:
  '@omdp/dsh-connector': true
  '@omdp/dsh-vision-bridge': true

Then re-run the add. (These plugins are plain JavaScript with no build step, so the whitelist is the only hurdle — no prepare script is needed. See the official publish.md for the full "build-script catch".) Treat the allowance as permission to run the package's code at install time; for untrusted sources, pin a commit (github:XJungit/omdp#<sha>&path:<subdir>).

The same monorepo layout is used by other DSH plugin collections, e.g. zhu1090093659/dsh-web-ui.

Installing from npm (recommended)

Both plugins are published to npm (@omdp/dsh-connector, @omdp/dsh-vision-bridge), automatically by GitHub Actions on every v* tag. This is the preferred install path — it avoids the git-#path: normalization, cross-resolution, and allowBuilds friction that GitHub installs cause (see the history in docs/npm-publish.md).

// ~/.dsh/profiles/<name>/package.json
"dependencies": {
  "@omdp/dsh-connector": "^0.1.0",
  "@omdp/dsh-vision-bridge": "^0.1.0"
}

cd ~/.dsh/profiles/<name>
pnpm install

Updating is a standard pnpm update:

cd ~/.dsh/profiles/<name>
pnpm update @omdp/dsh-connector @omdp/dsh-vision-bridge

No #path: spec, no allowBuilds gate, no one-shot repair script, no duplicate loader-id pitfalls — npm packages install as clean bundles.

Releasing a new version (GitHub Actions)

1. Bump version in dsh-connector/package.json and dsh-vision-bridge/package.json.
2. Commit, then tag and push:

   git tag v0.1.1
   git push origin master && git push origin v0.1.1

3. .github/workflows/publish.yml publishes both packages to npm with provenance.
4. Update your profile: pnpm update @omdp/dsh-connector @omdp/dsh-vision-bridge.

See docs/npm-publish.md for the full setup (npm token, GitHub Secret, troubleshooting).

Historical: GitHub and local-link installs

GitHub installs (dsh plugin add github:XJungit/omdp#path:<plugin>) worked but hit network/TLS friction (e.g. UNABLE_TO_VERIFY_LEAF_SIGNATURE) and pnpm's git-#path: normalization on update (which dropped the #path: spec and could cross-resolve both packages to the repo root). A one-shot repair script (~/.dsh/profiles/web/update-omdp.ps1) handled those, but npm installs make all of that unnecessary.

Local link: installs ("@omdp/<plugin>": "link:<abs-path>/omdp/<plugin>") still work: pnpm install creates a junction so the running plugin is the repo source, and updating = edit/pull + restart. They remain a good choice during active development.

Conventions

• Every plugin subdirectory is a standalone npm package with a dsh.bundle (and optionally dsh.client) manifest.
• Package names are scoped under @omdp/ to avoid colliding with upstream dsh-* packages on npm.
• Plugins in this repo are plain JavaScript (no build step), so both local-link and GitHub installs work without a compile stage.
• Installing locally is preferred: add "@omdp/<plugin>": "link:<abs-path>/omdp/<plugin>" to the profile's dependencies and run pnpm install — the plugin loads straight from the repo and updates with a restart. GitHub installs remain possible via github:XJungit/omdp#path:<plugin>; the repository-root package.json mirrors @omdp/dsh-connector so a pnpm-canonicalized bare-git install of dsh-connector still resolves (see above).
• _skeleton-client/ and _skeleton-host/ are copy-paste templates for new plugins; they are not installable bundles themselves.