Introduction

In DSH plugin development, the syntaxes for Cordis’s inject, effect, Config, events, and utility contracts are explicitly defined. It is easy to miss a detail if you have to check scattered documentation during development. Also, there is a lack of a quality gate that can be run repeatedly locally and in CI.

dsh-cordis-plugin-kit is an offline specification, scaffolding, and quality gate tool tailored for DeepSeek Harness/Cordis plugin development. It solidifies common development conventions and Cordis-related rules into executable checks. It is suitable for plugin initialization, local checks, pre-commit checks, pre-push checks, and CI checks.

What is it

  • Plugin name: dsh-cordis-plugin-kit
  • Maintainer: hinayoung23
  • License: MIT
  • Positioning: Offline specification, scaffolding, and quality gates
  • Current specification baseline: DeepSeek Harness 0.1.0-rc.7, @deepseek-ai/cordis 4.0.1
  • Dependencies: Zero production dependencies

Its main purpose is to turn specifications into runnable checks. After installation to DSH, it provides ctx.cordisPluginKit specification, static checks, and explicit quality gate services.

Core Features

  • Built-in 35 offline Cordis/DSH/Node.js/automation specifications, available by category or JSON output
  • Generates installable DSH bundle, lifecycle tests, quality budget, Git hooks, proxy instructions, and CI adaptation files
  • Static checks without executing code: manifest, bundle patch, inject, effect, Config, events, utility contracts, secrets, and dangerous APIs
  • Uses the project’s original package manager to execute tests, with timeout and output limits provided
  • Executes apply / dispose in an isolated subprocess using the target project’s real Cordis version
  • Repeats loading and unloading, measures p50/p95 latency and heap growth, and blocks delivery based on project budget
  • Performs debounced quick checks on save, and automatically upgrades quality gates on commit/push/package; the development listener only runs with pnpm dev, not as a system background process
  • Unified ci core compatible with GitHub, GitLab, Gitee, and any Node.js-runnable pipeline
  • Provides ctx.cordisPluginKit specification, static checks, and explicit quality gate services after installation to DSH
  • Zero production dependencies

Installation and Enablement

As a development tool installed in the project:

pnpm add -D dsh-cordis-plugin-kit

As a DSH bundle installed to DSH:

dsh plugin --profile web add dsh-cordis-plugin-kit

After installing to DSH, you can access the specification, static checks, and explicit quality gate services provided by ctx.cordisPluginKit in the DSH context.

The plugin runs within the permissions of the current DSH process. It is recommended to check the source code, dependencies, and license before installation.

Quick Start

First, initialize a plugin directory, then install dependencies and run the first check:

npx dsh-cordis-plugin-kit init ./my-cordis-plugin --name my-cordis-plugin --ci auto
cd my-cordis-plugin
pnpm install
pnpm check
pnpm dev

init generates installable DSH bundle, lifecycle tests, quality budget, Git hooks, proxy instructions, and CI adaptation files. pnpm check executes the static quality gate. pnpm dev starts the development listener; the listener is not a background service, it only exists when explicitly run, and stops when the terminal exits.

Checking Existing Projects

If the project already exists, you can use the following commands directly.

Offline Standards

npx dsh-cordis-plugin-kit standards

standards is used to view the built-in 35 offline Cordis/DSH/Node.js/automation specifications, supporting output by category or JSON.

Static Checks

npx dsh-cordis-plugin-kit check . --strict

check does not execute the target code. The check scope includes manifest, bundle patch, inject, effect, Config, events, utility contracts, secrets, and dangerous APIs. --strict is used for a stricter check mode.

Testing

npx dsh-cordis-plugin-kit test . --timeout 60000

test uses the project’s original package manager to execute tests, with timeout and output limits provided.

Debugging and Performance

npx dsh-cordis-plugin-kit debug . --provide tools,systemPrompt
npx dsh-cordis-plugin-kit perf . --iterations 50 --max-apply-ms 80

debug and perf execute the target plugin code and should only be used for projects you trust.

Checks that require executing target code run in an isolated subprocess and use the target project’s real Cordis version to execute apply / dispose. Performance checks repeat loading and unloading, measure p50/p95 latency and heap growth, and block delivery based on project budget. The subprocess has a default 30-second timeout.

Quality Gates and CI Core

npx dsh-cordis-plugin-kit checkpoint pre-push .
npx dsh-cordis-plugin-kit ci .

checkpoint is used for quality gates at critical nodes. It performs debounced quick checks on save and automatically upgrades quality gates on commit/push/package. ci executes the quality gate core used across pipelines.

CI Adaptation

The unified ci core is compatible with GitHub, GitLab, Gitee, and any Node.js-runnable pipeline. Generate or supplement CI adaptation files for existing projects:

dsh-cordis-kit automation setup . --ci auto
dsh-cordis-kit ci setup . --provider github
dsh-cordis-kit ci setup . --provider gitlab,gitee
dsh-cordis-kit ci setup . --provider all

These CI adaptations do not require platform API Tokens, only the pipeline needs the ability to checkout code, Node.js 22+, and install dependencies. Private npm sources or private dependencies are still configured according to the enterprise’s original credential management methods.

Use Cases and Considerations

Suitable for:

  • Developing DSH/Cordis plugins and requiring offline specifications, scaffolding, and repeatable quality gates
  • Wanting to execute staged checks during save, commit, push, package, and CI
  • Needing compatibility with GitHub, GitLab, Gitee, or enterprise internal Node.js pipelines

Notice:

  • The plugin runs within the permissions of the current DSH process. You should check the source code, dependencies, and license before installation
  • Quality gates can detect known patterns and regressions, but no static or dynamic tool can mathematically guarantee that the code is free of functional, performance, or security issues
  • High-risk plugins still require manual review, integration testing with real dependencies, and business-specific threat modeling
  • debug and perf execute the target plugin code and should only be used for projects you trust
  • Static check never executes the target code
  • The listener is not a background service, it only exists when explicitly running pnpm dev or dsh-cordis-kit watch ., and stops when the terminal exits
  • Git hooks and remote CI are still unskippable subsequent quality gates

Conclusion

dsh-cordis-plugin-kit places the specifications, scaffolding, and quality gates for DSH/Cordis plugin development in a single local toolchain, suitable for daily development, pre-commit checks, pre-push checks, and CI checks.