DSH Plugin Development
An unofficial, independently maintained Agent Skill for developing DeepSeek Harness plugins against the DSH version that will actually run them.
It is deliberately a thin router. The Skill decides which plugin form, source authorities, and acceptance evidence a task needs; current DSH APIs remain in the target checkout's code and documentation.
That split follows DSH's own documentation standard: Skills own reusable workflows and specialized decisions, while product and runtime contracts stay in docs or source. It is evidence of alignment with the inspected design, not an endorsement of this repository.
Why a thin router
- Less drift: manifests, service signatures, Client module rules, CLI flags, and test commands are read from the target DSH version instead of copied here.
- Bounded Skill context: the installed Skill contains only
SKILL.mdand display metadata. The entrypoint has hard limits of 120 lines and 12 KiB; supporting evidence is not injected unless it is needed. - Better first decision: it distinguishes four delivery modes—live dynamic, local overlay, workspace package, and installable bundle—then classifies Host, Client, or both.
- Evidence over ceremony: completion depends on the real entry path and observable behavior, not a generated skeleton, successful build, or agent self-report.
- Safer collaboration: it preserves dirty worktrees, keeps review/change/publish authority separate, and makes sensitive capture explicit.
This project does not claim DeepSeek endorsement. “Aligned” means the routing decisions were checked against named official source files at a pinned tag or commit. Stars and install counts are adoption signals, not proof that the Skill produces correct plugins.
What it handles
| Request | Route |
|---|---|
| Temporary plugin in a running Cordis creation session | The runtime-provided dynamic plugin Skill and live tools |
Private experiment loaded with --patch |
The version-matched first-plugin path and real overlay boot |
| Shipped Host or Web Client feature inside DSH | Repository architecture, nearest package rules, current extension point, and assembled tests |
| Independent plugin installed into a profile | Current publish/CLI/manifest sources and isolated artifact acceptance |
Exact package fields and APIs are intentionally absent. That omission is the maintenance strategy, not missing documentation.
Install
Latest channel:
npx skills add striveh/dsh-plugin-development@dsh-plugin-developmentImmutable initial release:
npx skills add https://github.com/striveh/dsh-plugin-development/tree/v0.1.0/skills/dsh-plugin-developmentTo inspect before installing:
npx skills add striveh/dsh-plugin-development --list
npx skills use striveh/dsh-plugin-development@dsh-plugin-developmentThen ask your coding agent, for example:
Use
$dsh-plugin-developmentto add an opt-in Host+Client DSH plugin that shows each LLM request and streamed response. Verify the real composition and browser journey.
The Skill follows the open Agent Skills directory format and has no MCP dependency, executable hook, credential request, or install script.
Compatibility evidence
The machine-readable record is compatibility/dsh.json.
| Evidence | Reviewed value | Meaning |
|---|---|---|
| Latest published DSH prerelease | dsh-v0.1.1-rc.1 / 528c682… |
All routing modes and authority paths reviewed against the tagged source |
DSH master route set |
528c682… (0.1.1-rc.1) |
Tracked docs and loader/client sources reviewed; this is not a tagged compatibility promise |
| Maintainer-recorded routing evals | evals/cases.json and the initial receipt |
Four fresh-context tasks were scored as routing and acceptance-plan passes; raw outputs and implementation runs were not published |
A weekly workflow checks both newly published GitHub releases and the Git blob digest of tracked DSH authorities. Arbitrary upstream commits do not create noise when those files are unchanged. A new published release, moved tag, missing source, or changed digest opens one machine-labeled issue and fails the compatibility workflow. A maintainer must review the diff and rerun all forward evals before advancing the record; the workflow never auto-claims compatibility.
Latest-channel copies retain their GitHub source. After a reviewed release, update with npx skills update dsh-plugin-development (add --global for a global installation). A tag-pinned copy stays pinned until another tag is installed. The GitHub repository remains canonical if the skills.sh page or audit snapshot is temporarily stale.
Validate locally
node scripts/verify.mjs
node scripts/check-upstream.mjs
python3 /path/to/skill-creator/scripts/quick_validate.py skills/dsh-plugin-development
DO_NOT_TRACK=1 npx --yes skills@1.5.23 add . --listThe repository validator checks the installed file set, frontmatter, size budget, compatibility schema, authority map, bilingual README requirements, and coverage of the four routing modes. The upstream check uses only public GitHub metadata unless GITHUB_TOKEN is supplied for a higher rate limit.
See CONTRIBUTING.md for the release and upstream-review procedure. Security and prompt-safety reports belong in SECURITY.md.
The initial evaluation does not establish token savings or generated-plugin success. evals/README.md defines the A/B evidence required before making those stronger claims.
License
MIT. DeepSeek Harness and DeepSeek names belong to their respective owners.