Not installable yet. Here is the wiring that was verified.

Prerequisites

• A DeepSeek Harness installation you are willing to modify. The verified build was 0.1.5-rc.1, a developer preview whose own documentation states there will be compatibility-breaking changes.
• Node.js and pnpm if you intend to install DSH plugins. The dsh plugin command forwards its arguments to pnpm, which must be on your path.
• A decision about DSH_HOME. It resolves as explicit configuration, then $DSH_HOME, then ~/.dsh, and it governs the profile root, settings, sessions, and credentials.
• Willingness to edit a profile patch file by hand. There is no installer path that does this for you.

Start DSH from a neutral working directory when you experiment. Its launcher rejects a launch environment that carries a competing configuration.

Install step by step

1. Treat this as unavailableDo not run an installer command for DSH. The CLI target list contains 18 tools and dsh is not one of them, so a --tool dsh invocation fails with an unknown tool error rather than installing anything.
2. Read the status before planning workThe target list, the adapter module registry, and the primary harness set are all hardcoded, so adding DSH is a deliberate contract change rather than a configuration toggle.
3. Reuse the skills you already have if you want partial value nowAn existing Codex install writes skills to ~/.agents/skills, which is also a DSH skill root at lower precedence than the project and DSH home roots.
4. Wire the skill filesystem by hand only if you are evaluatingThis is the verified manual route. It is not a supported install and it is not performed by any AGI Super Team command.

npx -y agi-super-team@latest --tool dsh
# error: unknown tool: dsh
npx -y agi-super-team@latest --tool dsh --install
# error: unknown tool: dsh

Both commands fail. Nothing is installed, and no partial state is written. When DSH becomes a target, the command will read the same way as the other primary harnesses. Until then, this page exists so that a reader is not left guessing whether support is missing or merely undocumented.

What the manual wiring looks like

DSH is not a plugin marketplace model. Plugins are installed with dsh plugin --profile <profile> add <package>, and the interface is started with dsh web. More importantly for this team, the component that discovers skills on disk ships disabled. The skill-filesystem plugin is off by default in the web profile, so files placed on disk do not become available until something enables it.

The verified route is a declarative patch in the profile that both enables the component and points it at a skill root:

# $DSH_HOME/profiles/<profile>/cordis.patch.yml
- id: skill-filesystem
  name: '@deepseek-ai/dsh-skill-filesystem'
  disabled: false
  config:
    customSkillDirs: [ /path/to/skill-root ]

This shape was verified on an isolated DSH_HOME without touching a real user directory. The patch took effect and the configuration dump annotated the line as patched by the profile patch file. A custom skill directory was reachable at runtime, and ~/.agents/skills, which is a lower-precedence root, was also reachable with real skills listed including this repository's orchestrator skill.

Check the result

If you applied the patch for evaluation, inspect the effective configuration rather than the file you wrote. A patch that parses is not a patch that took effect, and a skill root that is listed is not a skill that the model can call.

dsh --version
dsh <profile> --dump-config
dsh web

Look for the skill filesystem line being enabled and annotated as patched, and for your skill directory appearing in the resolved roots. Anything beyond that, including whether a session actually receives the team, was not observed.

Limitations

Read this section as the honest summary of the status.

• Not supported. There is no CLI target, no adapter module, no connection contract, and no receipt for DSH. It does not appear in the adapter manifest.
• Not verified at runtime in the way that matters. The skill roots were confirmed reachable from a headless probe on one preview build, but no real session was run to observe a team being loaded, delegated to, or reviewed.
• Preview software. The build in question is 0.1.5-rc.1. Both the patch format and the default component state can change without notice.
• Version-sensitive roots. Skill precedence runs from project directories through custom directories to the DSH home and the shared agents home. A profile patch can override the shared agents home, so a root being readable on one profile does not guarantee it on another.
• No agent story. Only the skill layer has a verified route. Role assembly through presets and personas remains an open design question.

Rollback and uninstall

Nothing was installed, so there is nothing this package needs to remove. If you applied the manual patch for evaluation, delete the added block from $DSH_HOME/profiles/<profile>/cordis.patch.yml or delete the file if you created it solely for this test, then confirm with a configuration dump that the skill filesystem is back to its default state for that profile.

If you pointed a custom skill directory at a checkout, remove the directory reference as well. Skills that arrived through an unrelated Codex install under ~/.agents/skills are that install's artifacts; remove them with the Codex uninstall path rather than by deleting the shared directory.