DeepSeek Harness: Publishing Plugins
Last updated: 2026-08-31
A well-written plugin running only on your own machine has limited value. Publishing to npm and GitHub lets other DSH users install and use it, integrating your plugin into the ecosystem. This lesson covers the full process from code to publication.
npm publish — it's writing a good README and compatibility declaration. Whether users can use your plugin depends on clear documentation.
📋 Prerequisites: Completed 15-define-tool.md, able to write complete tool plugins
1. What You'll Learn
- npm publishing process
- package.json dsh field
- dsh-plugin GitHub topic
- Version management and semver
- Compatibility declarations
- Plugin documentation writing
2. npm Publishing Process
(1) Pre-Publish Checklist
| Check Item | Command/Method |
|---|---|
| Code compiles | pnpm build |
| Tests pass | pnpm test |
| package.json correct | Check name/version/main |
| README exists | File exists with complete content |
| .npmignore configured | Exclude src/ and other dev files |
| npm logged in | npm whoami |
(2) ▶ Example 2
# Compile TypeScript
pnpm build
# Confirm output
ls dist/
# index.js index.d.ts ...
(3) ▶ Example 3
# First publish
npm publish --access public
# Publish after version update
npm version patch # 1.0.0 → 1.0.1
npm publish
(4) ▶ Example 4
# .npmignore
src/
tests/
tsconfig.json
*.tsbuildinfo
.git/
.vscode/
Only publish compiled output, not source code.
(5) Post-Publish Verification
# Install in another project
pnpm add @dsh-plugin/my-tool
# Verify import
node -e "console.log(require('@dsh-plugin/my-tool'))"
3. package.json dsh Field
(1) dsh Field Structure
{
"name": "@dsh-plugin/my-tool",
"version": "1.0.0",
"main": "dist/index.js",
"types": "dist/index.d.ts",
"dsh": {
"name": "my-tool",
"description": "A custom tool for DSH",
"services": ["tools"],
"inject": ["tools"],
"capabilities": [],
"compatibility": {
"dsh": ">=0.5.0",
"cordis": ">=1.0.0"
},
"permissions": [
"fs.read",
"network.outbound"
],
"config": {
"apiKey": {
"type": "string",
"required": true,
"description": "API key for the service"
}
}
}
}
(2) Field Descriptions
| Field | Type | Description |
|---|---|---|
name |
string | Plugin identifier (matches export const name) |
description |
string | Plugin description |
services |
string[] | Provided services list |
inject |
string[] | Required services list |
capabilities |
string[] | Implemented capabilities list |
compatibility |
object | Compatibility requirements |
permissions |
string[] | Required permissions |
config |
object | Configuration item descriptions |
(3) dsh Field Purpose
- At install time: DSH reads permissions to display permission requests
- At load time: DSH reads compatibility to check version compatibility
- At discovery time: npm search can filter by dsh field
4. dsh-plugin GitHub topic
(1) Adding a topic
Add the dsh-plugin topic in GitHub repository settings:
Repository Settings → Topics → Add topic: dsh-plugin
(2) topic Purpose
Other users search for plugins via topic:
# GitHub CLI search
gh search repos --topic dsh-plugin --sort stars
# GitHub web search
https://github.com/topics/dsh-plugin
(3) Recommended topic Combinations
dsh-plugin ← Required
deepseek-harness ← Optional, increases discoverability
Tool type ← e.g., database, search, devops
(4) Naming Conventions
| Location | Naming | Example |
|---|---|---|
| npm package name | @dsh-plugin/xxx |
@dsh-plugin/database |
| GitHub repo name | dsh-plugin-xxx |
dsh-plugin-database |
| Plugin name | xxx |
database |
5. Version Management and semver
(1) semver Rules
Version format: MAJOR.MINOR.PATCH
| Change Type | Version Change | Description |
|---|---|---|
| PATCH | 1.0.0 → 1.0.1 | Bug fix, backward compatible |
| MINOR | 1.0.0 → 1.1.0 | New feature, backward compatible |
| MAJOR | 1.0.0 → 2.0.0 | Breaking change |
(2) Version Change Guide
When to bump PATCH:
- Fix a tool bug
- Fix a config validation issue
- Documentation update
When to bump MINOR:
- Add a new tool
- Add a config option (with default)
- Add a capability implementation
- Add optional dependencies
When to bump MAJOR:
- Remove a tool
- Change tool parameter format
- Remove a config option
- Change inject list
- Change Capability interface
(3) npm version Command
# Bump PATCH
npm version patch -m "fix: resolve timeout issue"
# Bump MINOR
npm version minor -m "feat: add batch query tool"
# Bump MAJOR
npm version major -m "breaking: change tool parameter format"
(4) Pre-release Versions
# Alpha version
npm version prealpha --preid alpha
# 1.0.0 → 1.1.0-alpha.0
# Beta version
npm version prebeta --preid beta
# 1.0.0 → 1.1.0-beta.0
# RC version
npm version prerelease --preid rc
# 1.1.0-beta.0 → 1.1.0-rc.0
6. Compatibility Declarations
(1) Declaration in package.json
{
"dsh": {
"compatibility": {
"dsh": ">=0.5.0",
"cordis": ">=1.0.0",
"node": ">=18.0.0"
}
},
"peerDependencies": {
"@deepseek-ai/dsh": ">=0.5.0",
"@deepseek-ai/cordis": ">=1.0.0"
}
}
(2) Version Range Syntax
| Syntax | Meaning | Matching Versions |
|---|---|---|
>=0.5.0 |
Greater than or equal | 0.5.0, 0.6.0, 1.0.0 |
^0.5.0 |
Compatible with 0.5.x | 0.5.0 ~ 0.5.9 |
~0.5.0 |
Compatible with 0.5.0.x | 0.5.0 ~ 0.5.0.9 |
0.5.x |
Any 0.5 patch | 0.5.0 ~ 0.5.99 |
(3) Compatibility Check
# DSH built-in check
dsh plugin check @dsh-plugin/my-tool
# Output
✅ Compatible with dsh@0.5.0
✅ Compatible with cordis@1.0.0
⚠️ Requires Node.js >= 18.0.0 (current: 16.20.0)
(4) Handling Breaking Changes
When publishing a MAJOR version:
- Document all changes in CHANGELOG.md
- Provide a migration guide
- Maintain the old version for at least 6 months
- Mark "Breaking Changes" in README
7. Plugin Documentation Writing
(1) README Template
# @dsh-plugin/my-tool
> DSH plugin for [feature description]
## Installation
\```bash
dsh plugin add @dsh-plugin/my-tool
\```
## Configuration
\```yaml
plugins:
'@dsh-plugin/my-tool':
config:
apiKey: sk-xxx
maxRetries: 3
\```
## Provided Tools
| Tool | Description |
|:-----|:-----------|
| `my_tool` | Does something useful |
## Dependencies
- DSH >= 0.5.0
- Cordis >= 1.0.0
## Permissions
- fs.read
- network.outbound
### ▶ Example
\```text
👤 Alice: Analyze project with my_tool
🤖 Agent:
🔧 Using tool: my_tool
→ Result: ...
\```
## License
MIT
(2) Documentation Elements
| Element | Required | Description |
|---|---|---|
| Install instructions | ✅ | One-line install command |
| Config instructions | ✅ | YAML config example |
| Tool list | ✅ | All provided tools |
| Dependency declaration | ✅ | DSH/Cordis version requirements |
| Permission declaration | ✅ | Required permissions and reasons |
| Usage example | ✅ | At least one complete example |
| API docs | ⚠️ | If providing a Service |
| Migration guide | ❌ | Only for MAJOR versions |
(3) CHANGELOG Maintenance
# Changelog
## 1.1.0 (2026-08-20)
### Added
- batch_query tool for querying multiple paths
- Config option `maxDepth` for recursive analysis
### Fixed
- Timeout handling for large directories
## 1.0.0 (2026-08-01)
### Breaking
- Changed parameter format from `dir_path` to `path`
### Added
- Initial release with file_info tool
❓ FAQ
@dsh-plugin/ prefix?@dsh-plugin/ prefix makes searching and identification easier. Private plugins can use your own scope.github:user/repo. But npm installs are faster and more stable.bash npm unpublish @dsh-plugin/my-tool@1.0.0 Only within 24 hours of publishing, and cannot unpublish versions with existing dependents."types": "dist/index.d.ts" in package.json and include .d.ts files. Exclude source via .npmignore.bash # Local link testing cd dsh-plugin-my-tool npm link cd ../my-dsh-project npm link @dsh-plugin/my-tool # Verify dsh plugin list 📖 Summary
- npm publish flow: build → check →
npm publish - package.json
dshfield describes plugin metadata: services, dependencies, permissions, compatibility dsh-pluginGitHub topic lets others discover plugins via topic search- semver version management: PATCH (bug fix), MINOR (new feature), MAJOR (breaking change)
- Compatibility declared in both
dsh.compatibilityandpeerDependencies - README must include: installation, configuration, tool list, dependencies, permissions, examples
📝 Exercises
1. ⭐ Basic: Add a complete package.json (with dsh field) and README.md for your previously written file_count tool plugin. Test locally with npm link.
2. ⭐⭐ Intermediate: Following semver conventions, add a new feature (new tool) to your plugin, bump MINOR version. Then fix a bug, bump PATCH version. Record each npm version command's output.
3. ⭐⭐⭐ Challenge: Publish your plugin to npm (can be --access public or a local registry). After publishing, install from another project and verify all functionality works. Write a CHANGELOG.md documenting the version history.