Preface

DeepSeek Harness (dsh) makes models, tools, skills, sessions, and UIs all replaceable plugins. As the community repository grows rapidly, authors often only discover issues after importing a profile: missing main/types in the manifest, the name field in cordis.patch.yml mismatching the package name, missing critical entries in tsconfig, or leftover .ts files in build artifacts — all leading to runtime crashes.

These issues could have been caught before submission. The community plugin dsh-plugin-check consolidates manifest protocols, patch formats, build pitfalls, and hub inclusion status into a single scan. A model or CI can run plugin_check against a repository directory to get a JSON compliance report and fix suggestions. The check process is read-only, does not modify files, and does not perform builds on the target repository.

This article is collated by cross-referencing the community directory page, GitHub repository README, package.json, and source code. The community directory site deepseek-harness-plugin.com is an independent listing page and has no official affiliation with DeepSeek / HyperGAN. The official runtime is still subject to deepseek-ai/deepseek-harness.

What is this

dsh-plugin-check is a “Tools and Capabilities” plugin for DeepSeek Harness, maintained by the GitHub organization omdsh-dev, with the repository address at omdsh-dev/dsh-plugin-check and the MIT license. The directory listing date is 2026-08-15; as of the day this draft was verified, the GitHub repository has 23 stars (the directory page still shows 17, please refer to the repository page for accurate data).

It solves pre-release gatekeeping for plugin repositories, rather than adding business tools to agents. After installation, it registers a tool named plugin_check with a row ID of tool-plugin-check, and the npm package name is declared as @deepseek-ai/dsh-plugin-check. This scope name comes from the repository’s package.json, and the maintainer is still the community organization omdsh-dev — do not interpret it as an official DeepSeek package.

The current package.json version is 0.0.1, with private set to true, and the primary language is TypeScript. The repository README states that it has been validated for isolated consumption against the @deepseek-ai/dsh@0.1.0-rc.6 dependency line.

Core Features

Read-Only, Zero Business Dependencies

The security model is clearly outlined in the README:
- Read-Only: Only performs readdir/stat/readFile operations on the target repository, with no modifications or builds.
- Zero Business Dependencies: The check logic only uses Node built-in modules (fs/path/child_process). When mounted as a plugin, it still declares peers: @deepseek-ai/cordis@^4.0.1, @deepseek-ai/dsh-tools, @deepseek-ai/dsh-invariants; missing dependencies will be fallback-provided by the profile’s node_modules.
- Does not run tsc: All build pitfalls are detected via static text scanning.
- Hub Check Offline-First: First reads the local catalog (environment variable DSH_HUB_SOURCE or hub/ in the current directory), with gh calls only as a fallback; if all checks fail, it will be marked as skipped and not counted as a warning.

Source code comments also mention path containment (preventing escape from the target directory / following symlinks) and resource budgets. The tool timeout for plugin_check is 5000 milliseconds. scan will process up to 50 repositories, and symbolic link directories will be skipped.

Three Actions

Parameter Type Required Description
action string Yes check / scan / schema
path string No For check, this is the plugin repository directory; for scan, this is the parent directory; defaults to the current working directory
strict boolean No Upgrades warnings to errors and affects the verdict, defaults to false

The meanings of the three actions:
- check: Inspects a single plugin repository and outputs verdict / errors / warnings / suggestions.
- scan: Scans subdirectories starting with dsh- under the parent directory. The README summarizes this as “repositories with package.json”; the source code will also accept directories with dsh.plugin.json, SKILL.md, or catalog.json.
- schema: Outputs the full list of check items, severity levels, and applicable types for manual or model-based rule verification.

verdict rules: pass if there are 0 errors; fail if there are errors; warn if only warnings are present. When strict=true, warnings will be upgraded, which will change the final conclusion.

Apply Check Items by Repository Kind

The plugin first identifies the repository kind: registry / skill / collection / tool-bundle / bundle / infra / unknown. The README notes there are 33 total checks, which apply based on the repository kind, not all repositories running the same set of TypeScript bundle rules. The branching logic in the source code is:
- registry: Validates the dsh.plugin.json contract
- skill: Checks that SKILL.md exists and has name/description in its frontmatter
- collection: Checks catalog.json’s collection and plugins fields
- bundle / tool-bundle: Manifest + patch + build pitfalls + Profile Bundle ecosystem compliance
- unknown / infra: Marked as unsupported-kind, skips detailed checks and hub queries

For bundle / tool-bundle, the main categories listed in the README are:

Category Examples as Errors Examples as Warnings
Manifest Protocol no-manifest, invalid-name, missing-main-or-types, no-patch incomplete-files, missing-peer, no-bundle-decl
Patch Format malformed-patch, patch-name-mismatch, duplicate-row-id unexpected-fields
Build Pitfalls no-source-entry, no-tsconfig, missing-ts-ext-imports, lib-layout-mismatch, stale-ts-imports missing-rewrite-imports, types-path-mismatch, implicit-node-types, no-build-script
Ecosystem Compliance core-row-id (patch occupies official core rows: tools / session / llm / web / permission) missing-profile-install-example, manual-install-only, core-modification-required
Hub Inclusion not-in-hub (hub-skipped is marked as info)

The checks field in the report refers to the execution results of fixed check items (total / passed / failed / warned / skipped), not the number of issues.

The repository README also records that on 2026-08-08, the maintainer self-tested 8 internal plugins (time / encoding / json / calculator / csv / regex / markdown / session-health) and all passed; during the process, 4 real defects in old plugins were fixed (missing tsconfig trio, missing build / prepack scripts). This is the maintainer’s self-report, not a third-party review.

Installation and Activation

The installation command given on the community directory page is:

dsh plugin add github:omdsh-dev/dsh-plugin-check

Run this in the DeepSeek Harness terminal. For reproducible installations, pin the commit per the directory page instructions:

dsh plugin add github:omdsh-dev/dsh-plugin-check#<commit-hash>

The repository README recommends installing via Profile Bundle into a specific profile (for DSH 0.1.0-rc.6). There are two sets of configurations: web and headless, and installing to the web profile will not automatically overwrite the headless profile; dsh run defaults to headless:

# Interactive (web) profile
dsh plugin --profile web add github:omdsh-dev/dsh-plugin-check

# One-shot task (headless) profile
dsh plugin --profile headless add github:omdsh-dev/dsh-plugin-check

The package’s dsh.bundle.patch (the repository file is cordis.patch.yml) will insert the plugin into the profile’s layer stack after installation, with the ID tool-plugin-check.

When not using GitHub and instead using a local tarball, the README gives this syntax:

npm pack
dsh plugin --profile web add <path-to-npm-pack-output-tarball>

To verify that the row has been attached:

dsh --profile web --dump-config | grep tool-plugin-check

A runtime smoke test can be run with:

dsh run "Use the plugin_check tool to inspect a plugin repository"

The Node engine declared in package.json is ^22.19.0 || >=24.0.0. The README recommends using npx -p @deepseek-ai/dsh@0.1.0-rc.6 dsh web to start lib production mode, and advises against npm install -g global installation. For Windows paths, please use forward slashes, e.g. C:/Users/....

Typical Usage

After installation, point your working directory to the plugin repository you want to inspect, and have the model call plugin_check. Two examples directly from the repository README are below.

Inspect a single repository:

plugin_check { action: "check", path: "C:/Users/admin/Desktop/dshext/dsh-tool-csv" }

A successful output format given in the README is similar to:

{"repo":"dsh-tool-csv","kind":"tool-bundle","verdict":"pass","checks":{"total":24,"passed":24}}

Scan a batch of dsh-* repositories under a parent directory:

plugin_check { action: "scan", path: "C:/Users/admin/Desktop/dshext" }

The return structure includes root, scanned, and a reports array. Non-compliant repositories will include errors and suggestions.

When reviewing the rules before scanning a repository, set action to schema. The path parameter can be omitted to use the current working directory. Add "strict": true if you want to treat warnings as failures.

Applicable Scenarios and Notes

This tool is suitable for these situations:
- Developing your own DSH plugin and running pre-submission or pre-packaging gatekeeping checks
- Maintaining a set of dsh-* repositories and using scan to view aggregated results
- Having agents run plugin_check automatically after modifying plugin code and follow the suggestions to fix manifests and patches

Important notes before use:
1. Permissions: The plugin runs with the permissions of the current dsh process, and may execute code during installation. You should review the source code and MIT license before installing; for production environments, it is recommended to pin the commit hash.
2. This is not an official CLI: The tool plugin_check registered by this plugin is different from the dsh plugin check subcommand proposed in community discussions.
3. Read-only does not equal zero risk: The check logic claims not to modify the target repository, but the plugin itself runs inside the dsh process and can read paths you specify.
4. Kind detection skips some repositories: infra / unknown kinds will not run the 33 bundle checks; a missing hub listing will only be marked as skipped and should not be treated as “already included”.
5. Scan limit: A single scan can process up to 50 repositories, with a 5-second tool invocation timeout; for large numbers of repositories or slow disks, split the directory and run check individually for more stability.
6. Runtime is still in preview: The README targets the 0.1.0-rc.6 version on npm. DeepSeek Harness is still in developer preview, and the peer dependency range and patch protocol may change, so please refer to the current repository README for the latest information.

Summary

dsh-plugin-check turns the scenario of “only discovering manifest and build issues after importing a plugin” into a pre-emptive read-only scan. It applies rules based on repository kind and outputs JSON conclusions and fix suggestions, making it ideal for plugin authors and bulk maintenance scenarios.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-plugin-check/

GitHub: https://github.com/omdsh-dev/dsh-plugin-check