1. Define one user outcome
State what changes after installation, what the Bundle adds to DSH, 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; document them explicitly when unavoidable.
- Link the package to its 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 keeps newly discovered packages outside the public index until a recorded review confirms purpose, compatibility, limitations, and actions.