muen-plugins

Muen-authored plugins for the DeepSeek Harness (DSH) market. This is the source-of-truth repo for @muen/* plugin packages. They are published as GitHub Release tarballs (and installed by the standard market mechanism dsh plugin add), so they are versioned, updatable, and survive upstream DSH upgrades.

This is a monorepo: one subdirectory per plugin, so we can keep adding plugins (and forks of community plugins) without restructuring.

This repo is public, and that decides what belongs here

The rule is one question: does the plugin name or serve one client, or exist only for Muen's own install? Yes → it lives in the private sibling muen-collective/mitsumeru-plugins, not here. No → here, where it is safe for a stranger to read.

The asymmetry is why the default is to stay out: this repo cannot be un-published. Git history keeps what a later delete removes from the tree, so a client plugin pushed here is a permanent public record, while a plugin moved out of the private repo loses nothing but a copy. When it is genuinely unclear whether something is client-bound, it goes to the private repo until the founder answers.

Being shipped inside the app is a different axis and does not decide this one: the vendored set comes from SHIPPED_PLUGINS in the shell (packages/mitsumeru/src/main/harness.ts), and a plugin can ship without being a market listing — @muen/dsh-brand-mitsumeru is the example, since it carries Mitsumeru's own identity and is vendored into the public app release rather than offered to the market.

Skills and processes are not plugins and are not here: they live in the private muen-method (collaborator-only, decision 52), and workflow JSON lives in the private muen-workflows.

Naming schema (keep consistent — every plugin follows this)

<slug> is the plugin name after the @muen/ scope, so the package name, source dir, and market-entry short name all agree.

Layout

plugins/
  <slug>/                @muen/<slug>  (one subdir per plugin)
    package.json         name: @muen/<slug>, dsh.bundle.patch: ./cordis.patch.yml, files
    cordis.patch.yml     inserts the plugin row (id + name)
    lib/                 the built host + client bundles (raw JS, no build step)
    README.md            accurate description of what the plugin does

Adding a new plugin

1. plugins/<new-slug>/ with package.json (declare dsh.bundle.patch + dsh.client if it has UI), cordis.patch.yml (row id/name = @muen/<new-slug>), lib/, README.md.
2. Bump version. Add scripts to the root package.json (pack:<slug>).
3. To publish: tag a Release and the release.yml workflow packs THAT plugin and attaches its .tgz (see "Publish" below for the two tag forms), then open a PR to awesome-dsh-plugin/awesome-dsh-plugin adding data/plugins/muen-collective__muen-plugins--plugins-<slug>.yml.

Forking a community plugin (to improve the UI)

Put it in its own subdir plugins/<fork-slug>/, name it @muen/<fork-slug>, and:

• Credit the original author — keep their LICENSE/copyright in your package (MIT etc.), and note the fork provenance in the plugin's README.md (a FORK.md like the product repo's plugins/dsh-file-explorer/FORK.md). The market's fork rule: real code that does something, and dependencies must point at the original author's repo/package — don't re-upload upstream copies under your account and depend on those.
• Keep the plugin generic/configurable (no Muen secrets or a specific client baked in).

Publish (register with the DSH market)

The market (dshmarket) shows the curated catalog at awesome-dsh-plugin.com/plugins.json, which is generated from github.com/awesome-dsh-plugin/awesome-dsh-plugin's data/plugins/*.yml. To register a plugin:

1. Push this repo to GitHub and make it public; add the dsh-plugin topic. The repo must be ≥1 day old and ≥10 commits (CI checks this).
2. Tag a Release. release.yml runs node scripts/pack-all.mjs and attaches that plugin's .tgz to the GitHub Release (the market prefers a published npm package or a Release tarball over build-from-source). There are two tag forms:
   • <plugin>-vX.Y.Z — names its plugin, e.g. dsh-assets-v0.1.0. plugins/<plugin>/package.json must carry X.Y.Z. This is the form to use: several plugins here legitimately sit at 0.1.0 before their first release, and this form does not care.
   • vX.Y.Z — version-only, kept for the tags already out there. Exactly one plugin in the repo may carry X.Y.Z, or the release fails as ambiguous rather than guessing.
3. Open a PR to awesome-dsh-plugin/awesome-dsh-plugin adding ONE file data/plugins/muen-collective__muen-plugins--plugins-<slug>.yml. Example:

   url: https://github.com/muen-collective/muen-plugins/tree/main/plugins/dsh-brand-swap
   name: muen-collective/muen-plugins#dsh-brand-swap
   category: theme
   description:
     en: White-label brand swap for DeepSeek Harness. Replaces the DeepSeek mark in the sidebar and conversation-hero brand slots with a per-profile wordmark, colors and font (each Brand OS configures its own identity on the plugin row). Ships neutral defaults.

4. Verify from a fresh profile: dsh plugin --profile demo add <tarball-url | github:...>.

Update an entry the same way — edit only your data/plugins/*.yml and regenerate (node scripts/generate-readme.mjs).

Value separation

Published plugins are neutral/generic — no client (or Muen) brand is baked into the package. Per-profile config: on a plugin's cordis.patch.yml row supplies the specific values (e.g. a client's wordmark via the brand-swap row's wordmark/fontFamily/dotColor). The market card can show a branded screenshot as an illustration; the shipped package stays neutral.

History note

This repo previously held the old @muen/mitsu-* surface plugins (assets, docs, write, krea, runninghub, modes, rail, settings, sidebar-tree, task-switcher, starter-pack, updater, open-in-sidebar, browser). Those were failed experiments and are permanently deleted. The brand plugin was generalized on 2026-09-04 to the white-label @muen/dsh-brand-swap (row brand-swap, service brand) — one generic plugin every Brand OS (mitsu, yammaman, vent) configures with its own identity; the Mitsumeru app's internal copy keeps the legacy @muen/mitsu-brand identity (row mitsu-brand, service mitsu.brand) until the next app release. Everything else is sourced from the community DSH market. Do not recreate, publish, or reference deleted @muen/mitsu-* names as live plugins.

Optional: npm

If you later prefer the @muen npm scope, npm publish each package (needs @muen scope ownership

• auth) and point the catalog url at the npm package instead.