plugin-write
Write DeepSeek Harness Plugins
Create a plugin package. First classify the repository mode and plugin form, then read the matching reference files, and finally validate the published entry with the smallest set of gates that covers the change.
Select the Repository Mode First
| Target | Rules to apply |
|---|---|
A package inside the official deepseek-harness monorepo |
Use the in-repository package, tsconfig, documentation, and root-gate rules below. |
| An externally installable DSH plugin | Preserve that repository's package layout and scripts. Use only packages and exports published by the exact target DSH version. Do not copy private, workspace versions, root tsconfig registration, or monorepo-only README gates. |
| An existing plugin being adapted to a new DSH host | Read references/version-adaptation.md, build the complete version corridor, and run the seven-class touchpoint preflight. If a change is breaking and the user has not yet authorized implementation, present the migration plan and wait for confirmation. After authorization, complete the version adaptation before using this Skill's form references. Form examples must never override target source, type declarations, or release notes. |
Derive Cordis, Schemastery, and DSH package names and version ranges from the manifest of the exact target version. Current examples use scoped @deepseek-ai/* identifiers. Older targets may differ and must follow their own published contracts.
For every new external plugin, read references/naming-conventions.md before choosing public identifiers. Create dsh-plugin.naming.json at the plugin repository root and run the bundled read-only validator before final package validation. Treat compatibility errors as target-contract failures and prefix warnings as community recommendations; use --strict only when the plugin adopts the collision-resistant profile. This is not an official Harness manifest or a global reservation. For an existing external plugin, report naming deviations but preserve published names unless the user explicitly authorizes a compatibility-breaking rename. Packages inside the official monorepo follow the exact target checkout instead of this external naming profile.
After the offline declaration passes, read references/registry-check.md and run the separate central lookup when public network access is available. Supply the exact target Harness version and preserve the reported index SHA-256 with the source URL as evidence. Treat a completed no-match result only as “no reviewed match”; treat timeout, malformed data, unsupported contract, oversized input, or network failure as “unknown/not checked.” Never let the online lookup modify the local manifest, automatically rename a published surface, or turn an automated discovery candidate into a reservation. When central registration is explicitly selected, prepare the full v2 entry and run the central repository's check and verify-source commands before copying it into registry/entries. Validation does not authorize submitting a PR; a formal reservation exists only after a source-backed entry is reviewed and merged in the central registry.