Introduction¶

People running agents with DSH often encounter a class of problems: the model confidently claims “I remember this context,” “The plan is set,” “The benchmark passed,” “This release is fine,” but you can’t find the basis for its conclusion. It just asserts, without evidence.

Existing practices usually add a few lines like “Please be cautious” or “Please explain the basis” to the system prompt, or install a separate skill pack for each scenario. The former has very weak constraints; the latter scatters the same discipline across five packs, each requiring installation and taking up a slot in the index.

dsh-ops-kit is a plugin submitted to the SkillHub community directory by maintainer YaoleWu, categorized under workflows, currently with 2 stars. It condenses the discipline into one sentence: Before an agent says “I remember,” “The plan is feasible,” “The baseline passed,” or “The release is safe,” it should be able to point to evidence. Five read-only skill packs share this principle, accompanied by a runtime doctor to check compatibility with the official PTY prompt handshake.

Positioning¶

One sentence: dsh-ops-kit is a read-only capability pack for the DeepSeek Harness. It bundles memory retrieval, orchestration planning, agent loop rules, benchmark result gatekeepers, and release checklists, providing the agent with a “vocabulary of plans, checks, and evidence,” without executing side-effecting operations itself.

It explicitly does not do these things: it does not silently create issues, call remote APIs, start benchmarks, modify the repository, or read credentials. All side-effecting actions are left outside the pack, becoming an explicit, auditable operation.

By the way, the basis for “read-only”: in the list of tools, only Git-first memory and repository audit are marked as Read-only; the rest are marked as None (no side effects). The pack itself does not download credentials, inject runtime output, or contain machine-related configuration.

Core Capabilities¶

The plugin registers eight tools, divided by capability pack as follows.

Capability pack                    Tool                         Purpose                                   Side Effects
Capability index                   dsh_ops_capability_catalog   List contained capability packs           None
Evidence-based orchestration       dsh_ops_workflow_plan        Produce scope → baseline → context →
                                                                    execute → verify → handoff plan          None
Skill reference                    dsh_ops_skill_read           Read full skill definition inside the pack None
Git-first memory                   dsh_ops_memory_search        Search previous context in limited local Markdown / code root directory
                                                                    with source attribution                Read-only
Repository audit                   dsh_ops_repository_audit     Audit Git cleanliness, untracked files,
                                                                    credential path hygiene                Read-only
Release hygiene                    dsh_ops_release_checklist    Produce complete DSH plugin release checklist None
Release verification               dsh_ops_plugin_doctor        Check plugin repository installability and
                                                                    publishability item by item            Read-only
Runtime health                     dsh_ops_runtime_doctor       Check official terminal / persistent-bash
                                                                    prompt compatibility                   Read-only

Three design trade-offs are worth mentioning separately.

First, orchestration rules are not made into independent tools. Agent loop rules such as leader-only dispatch, shared worktree coordination, runtime ownership, and cleaning evidence, as well as the manifest, precheck, artifact list, and result integrity check for the benchmark gatekeeper, are all embedded in the workflow-plan and release-checklist skills.

Second, the checklist and verification are two separate tools. dsh_ops_release_checklist states “what is needed for a release,” and dsh_ops_plugin_doctor uses it to measure “whether it was actually achieved.” The explanation in the README is that a checklist that no one checks is a pitfall where a startup suite prints SKIPPED then exit 0, CI turns green while integration checks don’t run, or a plugin gets stuck at "private": true and cannot be released.

Third, the doctor only checks and does not modify. It verifies whether dsh.bundle plus cordis.patch.yml can be installed, whether patch lines correspond to package names, whether private / files / exports are publishable, whether @deepseek-ai/* remains a peer dependency, and whether the startup suite prints SKIPPED then exit 0. It never edits node_modules itself.

Installation and Activation¶

Installation goes through the registry, requires no build steps, and does not require allowBuilds approval.

dsh plugin --profile <profile> add dsh-ops-kit

If you wish to manually edit the profile manifest, the equivalent code is as follows.

// ~/.dsh/profiles/<profile>/package.json
{
  "dependencies": {
    "dsh-ops-kit": "^0.1.0"
  },
  "dsh": {
    "profile": {
      "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-ops-kit"]
    }
  }
}

After editing, reinstall dependencies and restart the profile for that profile.

The package version is 0.1.1, license is MIT, Node requires >=22.19.0, and @deepseek-ai/cordis, @deepseek-ai/dsh-skill, @deepseek-ai/dsh-tools are declared as peer dependencies. The package also comes with a protected dsh-terminal-hotfix command that only patches the official rc.6 compile entry after an exact layout match, generates a timestamped backup before changes, and verifies the prompt handshake after applying:

dsh-terminal-hotfix --check
dsh-terminal-hotfix --apply

After applying, you need to restart DSH. This command is not automatically executed by the plugin loader and will not silently modify dependencies.

Configuring Local Search Root Directory¶

dsh_ops_memory_search and dsh_ops_repository_audit need to limit the directories that can be checked. The root directory should be as narrow as possible and never point to a credentials directory.

# example overlay; adapt to the profile's configuration format
- id: dsh-ops-kit
  config:
    roots:
      - /workspace/project
      - /workspace/memory
    maxFiles: 120
    maxBytesPerFile: 160000

If roots are not configured, the tools default to the current working directory of the DSH process. Credential class paths and common run/secret directories will be rejected or skipped.

Typical Usage and Verification¶

The verification chain after installation is as follows; walk through it in this order.

pnpm install --offline --ignore-scripts
pnpm build
pnpm typecheck
pnpm test

After installing in a real profile, the README suggests confirming item by item: DSH endpoint returns HTTP 200, profile runs after restart, skills in the package are listed, dsh_ops_capability_catalog returns all capability packs, and dsh_ops_runtime_doctor status is healthy.

If the doctor reports terminal-prompt-mismatch, use dsh-terminal-hotfix --check to confirm first, then decide whether to apply a rollback patch.

Applicable Scenarios and Considerations¶

Suitable for these people: those already using DSH for multi-step research, multi-agent collaboration, benchmarking, or plugin release processes, and who want the agent to stop at critical nodes to provide evidence rather than directly giving a conclusion. The solution in the plugin is conservative; if you need aggressive auto-execution, it is not suitable.

Three points must be made clear.

First, the plugin runs with the permissions of the current DSH process. Review the source code and license yourself before installing. The license is MIT, and the README states this is an independent integration layer distilled from general engineering practices, not a copy of any internal repository. The package does not contain credentials, private data, runtime output, or machine-related configuration.

Second, in the embedded package.json fragment in the README, the repository / bugs / homepage fields are written as LeslieWylie/dsh-ops-kit, which is inconsistent with the maintainer YaoleWu recorded on the community directory page. The files field lists README.zh.md, which is not clearly linked in this README’s navigation. For discrepancies like these, the actual repository should take precedence before installation.

Third, SkillHub is an independent site with no official affiliation with DeepSeek or Firmian, and is not an official app store. The star count and classification above come from the records on that directory page.

Summary¶

The value of dsh-ops-kit is not in quantity, but in spreading the same discipline—conclusions need evidence—across memory, orchestration, benchmarking, and release. It ensures that every step of the agent falls on an auditable, read-only check. If your process in DSH carries the risk of “looking right but unverified,” you can start with the two tools dsh_ops_capability_catalog and dsh_ops_runtime_doctor. They have no side effects and can first tell you what the pack contains and whether the runtime is healthy.

Directory page: https://www.skillhub.cn/plugins/YaoleWu/dsh-ops-kit
Repository: https://github.com/YaoleWu/dsh-ops-kit