1. Define one user outcome
State what changes after installation, which capabilities are added, which Profile is targeted, and what the user can do next. Do not use “plugin” as a label for an unrelated repository.
2. Declare the Bundle patch
Your package manifest must point to the patch shipped in the distribution.
{
"name": "your-package",
"version": "1.0.0",
"dsh": { "bundle": { "patch": "cordis.patch.yml" } }
}3. Make the distribution auditable
- Commit the manifest and patch to source control.
- Publish the same version named by the install command.
- Ensure the npm tarball or Git commit contains both files.
- Avoid hidden downloads and lifecycle scripts; if they are necessary, document them explicitly.
- Link the package back to the canonical source repository.
4. Document the full lifecycle
- Prerequisites and supported Harness baseline.
- Target Profile and version-pinned install command.
- A concrete verification step.
- Update and remove commands.
- Network, filesystem, credentials, shell, native build, and external runtime facts.
- Known limitations and data that can remain after removal.
5. Publish evidence, not promises
A reproducible package, immutable commit, and clear lifecycle let users make a decision. Popularity and broad safety claims do not replace those facts. DSHub places newly discovered packages in a private review queue until a human confirms their purpose, compatibility, limitations, and actions.