DeepSeek Harness: プラグインの公開
最終更新:2026-08-31
よく書けたプラグインが自分のマシンでしか動かないのは価値が限られます。npm や GitHub に公開することで、他の DSH ユーザーがインストール・使用でき、プラグインがエコシステムに統合されます。このレッスンではコードから公開までの全プロセスを解説します。
💡 ヒント:公開前の最も重要なステップは
npm publish ではなく、良い README と互換性宣言を書くことです。ユーザーがあなたのプラグインを使えるかどうかは、明確なドキュメント次第です。
📋 前提知識:15-define-tool.md の完了、完全なツールプラグインが書けること
1. 学習内容
- npm 公開プロセス
- package.json dsh フィールド
- dsh-plugin GitHub topic
- バージョン管理と semver
- 互換性宣言
- プラグインドキュメントの書き方
2. npm 公開プロセス
(1) 公開前チェックリスト
| チェック項目 | コマンド/方法 |
|---|---|
| コードがコンパイル可能 | pnpm build |
| テストが通る | pnpm test |
| package.json が正しい | name/version/main を確認 |
| README が存在 | ファイルがあり内容が充実 |
| .npmignore が設定済み | src/ 等の開発ファイルを除外 |
| npm にログイン済み | npm whoami |
▶ サンプル 2:
BASH
# TypeScript をコンパイル
pnpm build
# 出力を確認
ls dist/
# index.js index.d.ts ...
▶ サンプル 3:
BASH
# 初回公開
npm publish --access public
# バージョン更新後の公開
npm version patch # 1.0.0 → 1.0.1
npm publish
▶ サンプル 4:
TEXT
📖 参照専用
# .npmignore
src/
tests/
tsconfig.json
*.tsbuildinfo
.git/
.vscode/
コンパイル済み出力のみを公開、ソースコードは含めない。
(5) 公開後の確認
BASH
# 別のプロジェクトでインストール
pnpm add @dsh-plugin/my-tool
# インポートを確認
node -e "console.log(require('@dsh-plugin/my-tool'))"
3. package.json dsh フィールド
(1) dsh フィールドの構造
JSON
{
"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) フィールドの説明
| フィールド | 型 | 説明 |
|---|---|---|
name |
string | プラグイン識別子(export const name と一致) |
description |
string | プラグインの説明 |
services |
string[] | 提供するサービスリスト |
inject |
string[] | 必要なサービスリスト |
capabilities |
string[] | 実装するケイパビリティリスト |
compatibility |
object | 互換性要件 |
permissions |
string[] | 必要なパーミッション |
config |
object | 設定項目の説明 |
(3) dsh フィールドの用途
- インストール時:DSH が permissions を読み取りパーミッション要求を表示
- ロード時:DSH が compatibility を読み取りバージョン互換性をチェック
- 発見時:npm 検索で dsh フィールドによるフィルタリングが可能
4. dsh-plugin GitHub topic
(1) topic の追加
GitHub リポジトリ設定で dsh-plugin topic を追加:
TEXT
📖 参照専用
Repository Settings → Topics → Add topic:dsh-plugin
(2) topic の用途
他のユーザーが topic 経由でプラグインを検索:
BASH
# GitHub CLI 検索
gh search repos --topic dsh-plugin --sort stars
# GitHub Web 検索
https://github.com/topics/dsh-plugin
(3) 推奨 topic 組み合わせ
TEXT
📖 参照専用
dsh-plugin ← 必須
deepseek-harness ← 推奨、発見性向上
ツールタイプ ← 例:database, search, devops
(4) 命名規則
| 場所 | 命名 | 例 |
|---|---|---|
| npm パッケージ名 | @dsh-plugin/xxx |
@dsh-plugin/database |
| GitHub リポジトリ名 | dsh-plugin-xxx |
dsh-plugin-database |
| プラグイン名 | xxx |
database |
5. バージョン管理と semver
(1) semver ルール
バージョン形式:MAJOR.MINOR.PATCH
| 変更タイプ | バージョン変化 | 説明 |
|---|---|---|
| PATCH | 1.0.0 → 1.0.1 | バグ修正、後方互換 |
| MINOR | 1.0.0 → 1.1.0 | 新機能、後方互換 |
| MAJOR | 1.0.0 → 2.0.0 | 破壊的変更 |
(2) バージョン更新ガイド
TEXT
📖 参照専用
PATCH を更新するケース:
- ツールのバグ修正
- 設定バリデーションの修正
- ドキュメント更新
MINOR を更新するケース:
- 新しいツールの追加
- 設定オプションの追加(デフォルト値あり)
- ケイパビリティ実装の追加
- オプショナル依存関係の追加
MAJOR を更新するケース:
- ツールの削除
- ツールパラメータ形式の変更
- 設定オプションの削除
- inject リストの変更
- Capability インターフェースの変更
(3) npm version コマンド
BASH
# PATCH を更新
npm version patch -m "fix:resolve timeout issue"
# MINOR を更新
npm version minor -m "feat:add batch query tool"
# MAJOR を更新
npm version major -m "breaking:change tool parameter format"
(4) プレリリースバージョン
BASH
# Alpha 版
npm version prealpha --preid alpha
# 1.0.0 → 1.1.0-alpha.0
# Beta 版
npm version prebeta --preid beta
# 1.0.0 → 1.1.0-beta.0
# RC 版
npm version prerelease --preid rc
# 1.1.0-beta.0 → 1.1.0-rc.0
6. 互換性宣言
(1) package.json での宣言
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) バージョン範囲構文
| 構文 | 意味 | マッチするバージョン |
|---|---|---|
>=0.5.0 |
以上 | 0.5.0, 0.6.0, 1.0.0 |
^0.5.0 |
0.5.x 互換 | 0.5.0 ~ 0.5.9 |
~0.5.0 |
0.5.0.x 互換 | 0.5.0 ~ 0.5.0.9 |
0.5.x |
0.5 パッチ全般 | 0.5.0 ~ 0.5.99 |
(3) 互換性チェック
BASH
# DSH 内蔵チェック
dsh plugin check @dsh-plugin/my-tool
# 出力
✅ Compatible with dsh@0.5.0
✅ Compatible with cordis@1.0.0
⚠️ Requires Node.js >= 18.0.0 (current:16.20.0)
(4) 破壊的変更の扱い
MAJOR バージョン公開時:
- CHANGELOG.md にすべての変更を記録
- マイグレーションガイドを提供
- 旧バージョンを最低6ヶ月は保守
- README に「Breaking Changes」をマーク
7. プラグインドキュメントの書き方
(1) README テンプレート
MARKDOWN
# @dsh-plugin/my-tool
> DSH plugin for [機能説明]
## インストール
\```bash
dsh plugin add @dsh-plugin/my-tool
\```
## 設定
\```yaml
plugins:
'@dsh-plugin/my-tool':
config:
apiKey:sk-xxx
maxRetries:3
\```
## 提供ツール
| Tool | Description |
|:-----|:-----------|
| `my_tool` | 何か便利なことをする |
## 依存関係
- DSH >= 0.5.0
- Cordis >= 1.0.0
## パーミッション
- fs.read
- network.outbound
### ▽ サンプル
\```text
👤 Alice:Analyze project with my_tool
🤖 Agent:
🔧 Using tool:my_tool
→ Result:...
\```
## ライセンス
MIT
(2) ドキュメント要素
| 要素 | 必須 | 説明 |
|---|---|---|
| インストール手順 | ✅ | ワンラインインストールコマンド |
| 設定手順 | ✅ | YAML 設定例 |
| ツールリスト | ✅ | 提供するすべてのツール |
| 依存関係宣言 | ✅ | DSH/Cordis バージョン要件 |
| パーミッション宣言 | ✅ | 必要なパーミッションと理由 |
| 使用例 | ✅ | 少なくとも1つの完全な例 |
| API ドキュメント | ⚠️ | Service を提供する場合 |
| マイグレーションガイド | ❌ | MAJOR バージョンのみ |
(3) CHANGELOG の保守
MARKDOWN
# 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
❓ よくある質問
Q
@dsh-plugin/ プレフィックスは必須?A 推奨ですが必須ではありません。
@dsh-plugin/ プレフィックスは検索と識別が容易です。プライベートプラグインは独自のスコープを使用可能。Q npm に公開せず GitHub のみで公開できますか?
A はい。ユーザーは
github:user/repo でインストール可能。ただし npm インストールの方が高速で安定。Q 公開済みバージョンを取り下げるには?
A
bash npm unpublish @dsh-plugin/my-tool@1.0.0 公開後24時間以内のみ可能、かつ依存があるバージョンは取り下げ不可。Q TypeScript ソースコードを公開すべき?
A 推奨。package.json に
"types":"dist/index.d.ts" を設定し、.d.ts ファイルを含める。ソースは .npmignore で除外。Q 公開前にプラグインをテストするには?
A
bash # ローカルリンクテスト cd dsh-plugin-my-tool npm link cd ../my-dsh-project npm link @dsh-plugin/my-tool # 確認 dsh plugin list Q 公開後にバグを見つけた場合は?
A バグ修正 → patch バージョン更新 → 公開。既に公開されたバージョンを変更しないこと。
📖 まとめ
- npm 公開フロー:build → check →
npm publish - package.json の
dshフィールドがプラグインメタデータを記述:services、依存、permissions、compatibility dsh-pluginGitHub topic で他のユーザーがトピック検索でプラグインを発見可能- semver バージョン管理:PATCH(バグ修正)、MINOR(新機能)、MAJOR(破壊的変更)
- 互換性は
dsh.compatibilityとpeerDependenciesの両方で宣言 - README には必須:インストール、設定、ツールリスト、依存、パーミッション、使用例
📝 練習問題
1. ⭐ 基礎:以前に書いた file_count ツールプラグインに完全な package.json(dsh フィールド付き)と README.md を追加してください。npm link でローカルテスト。
2. ⭐⭐ 応用:semver 規約に従い、プラグインに新機能(新しいツール)を追加して MINOR バージョンを更新してください。その後バグを修正して PATCH バージョンを更新。各 npm version コマンドの出力を記録。
3. ⭐⭐⭐ チャレンジ:プラグインを npm に公開(--access public またはローカルレジストリ)。公開後、別のプロジェクトからインストールし、すべての機能が動作することを確認。CHANGELOG.md でバージョン履歴を記録。