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.md and 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-development

Immutable initial release:

npx skills add https://github.com/striveh/dsh-plugin-development/tree/v0.1.0/skills/dsh-plugin-development

To inspect before installing:

npx skills add striveh/dsh-plugin-development --list
npx skills use striveh/dsh-plugin-development@dsh-plugin-development

Then ask your coding agent, for example:

Use $dsh-plugin-development to 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 . --list

The 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.